Since upgrading app-shells/dash to version 0.5.8.2, KDE and pm-suspend have been silently failing. Checking /var/log/pm-suspend.log, I see this entry: Thu Jul 16 00:11:50 EDT 2015: performing suspend sh: echo: I/O error Thu Jul 16 00:11:50 EDT 2015: Awake. Manually suspending by echoing "mem" to /sys/power/state works correctly. pm-suspend and KDE also work if dash is downgraded to 0.5.7.4, or if /bin/sh is switched back to bash. Reproducible: Always Steps to Reproduce: 1. Set dash as /bin/sh. 2. Upgrade dash to 0.5.8.2. 3. Attempt to suspend to RAM or disk using pm-suspend, pm-hibernate, or KDE's suspend functions. Actual Results: System will act as if nothing happened. (If using KDE's suspend, it may lock the screen.) Expected Results: System should go into suspend or hibernate, depending on the option selected.
I'm hit by this one as well. Currently working around it by reverting /bin/sh to bash, but I only did it on a hunch (hadn't noticed the dash upgrade). Other users might have a much harder time finding a workaround.
I don't get an echo I/O error in pm-suspend.log. It says it goes to sleep in the log and then immediately logs that it wakes back up again without ever going to sleep.
(In reply to Matthew Schultz from comment #2) > I don't get an echo I/O error in pm-suspend.log. It says it goes to sleep > in the log and then immediately logs that it wakes back up again without > ever going to sleep. My workaround is to mask app-shells/dash-0.5.8.2 and downgrade to 0.5.7.4 since it is still available and stable.
In dash-0.5.8.2, "echo -n foo" instead of printing "foo" without a newline, prints "-n foo". So of course when pm-utils does things like this: echo -n "mem" > /sys/power/state you get an I/O error. This change in behavior contradicts dash's man page: echo [-n] args... Print the arguments on the standard output, separated by spaces. Unless the -n option is present, a newline is output following the arguments. Worse, it violates Ubuntu's promise that "echo -n" is guaranteed to be supported in /bin/sh (see https://wiki.ubuntu.com/DashAsBinSh); so all sorts of system shell scripts in packages whose authors use Ubuntu and Debian will now also start failing. I suggest that either dash needs to be fixed, or should not be used as /bin/sh any more. Assigning to dash maintainers.
i will update the man page, but the upstream promise is irrelevant. `echo -n` is not portable and no shell scripts that have #!/bin/sh may use it. the fact that some scripts were tested on debian/ubuntu/whatever when /bin/sh->dash is entirely irrelevant -- dash is not the only shell out there. you could make the same invalid argument by saying "i tested it on my distro and it worked when /bin/sh->bash". if you have a script using `echo -n` then you need to fix it to be portable like `printf %s ...`.
(In reply to SpanKY from comment #5) OK, fixed in pm-utils-1.4.1-r7. Although I personally think that gentoo's modifications to standard dash behavior are dangerous and misguided. Patch submitted upstream at https://bugs.freedesktop.org/show_bug.cgi?id=91497 +*pm-utils-1.4.1-r7 (29 Jul 2015) + + 29 Jul 2015; Alexandre Rostovtsev <tetromino@gentoo.org> + +pm-utils-1.4.1-r7.ebuild, +files/1.4.1-echo-n.patch: + Fix suspend/hibernate failure when using strange shells like dash-0.5.8.2 + (bug #555032, thanks to David Korth et al.
(In reply to Alexandre Rostovtsev from comment #6) that might be your view if you don't care about portability. the fact that we've changed dash to behave this way means we notice & fix problems that other shells can/do run into, but have fewer users so it's not reported nearly as often. what's dangerous is saying "i hate bashisms, but dashisms are OK". it's also fairly disingenuous.
(In reply to SpanKY from comment #7) I thought the purpose of dash isn't to act as a test suite for posix compatibility, it's to be a practical, safe, low-memory-use alternative to bash for executing existing scripts. I mean, the "-n" behavior that was recently added diverges from upstream dash, diverges from bash, diverges from all bsds, diverges even from solaris (which does crazy things with "-n" but at least treats it as a flag!), and as far as I can see for no good reason besides "posix allows it".
(In reply to Alexandre Rostovtsev from comment #8) > solaris (which does crazy things with "-n" but at least treats it as a flag!) Brain error, I am wrong about solaris.
(In reply to Alexandre Rostovtsev from comment #8) the point of converting the system to use #!/bin/sh is to enable more shells (including, but absolutely not limited to, dash) by forcing scripts to only use the POSIX subset. nowhere did we agree to replace one set of set of non-portable extensions (bashisms) with a different set (dashisms). the biggest driving reason was that bash was slow so people wanted *something* that was faster. dash was selected purely because it was smaller/faster than bash, not because it was dash. i stripped down the echo in dash because it was causing problems (treated some inputs differently from bash), and because it makes it smaller/faster, and because POSIX permits it, and because it allows us to catch *real* bugs like the one in pm-utils. the reason POSIX makes -n behavior optional is because not all shells agreed on its behavior. so listing a bunch of shells that do support -n is irrelevant -- there are shells that do not do that. like the build of dash that Gentoo ships, or busybox built w/fancy echo turned off (for size), or sash (will actually issue an error if you pass it -n). conversely, your argument appears to be "i want to use echo -n because dash supports it". if you want to be non-portable, then don't use #!/bin/sh.
the only reasonable point you could make is that i've broken scripts that explicitly use #!/bin/dash with the expectation of having dash extensions. if such a real world case comes up, i can consider how to handle it, but i have yet to see such a case. i have seen a few #!/bin/dash, but it was only as a forcing function because they weren't sure /bin/sh if pointed to bash and wanted to keep non-portable constructs from slipping in.
