"Amos Shapira" <[EMAIL PROTECTED]> writes: > On 22/11/2007, Oleg Goldshmidt <[EMAIL PROTECTED]> wrote: > >> what not that expect echo options, regular expressions, and other >> stuff ash/dash does not provide. Yes, I realize that it is technically >> careless. That's no excuse for keeping the default interactive shell >> different from the default environment shell on a desktop system. > > I'm not sure what does the "default interactive shell" have to do here > - properly-written shell scripts shouldn't depend on their > environment
So we agree... ;-) > I used to use tcsh as my interactive shell for over a decade, and it > (and /bin/csh) used to be the default shell assigned to new users on > many systems I worked on. But t?csh was *not* the default interactive shell on those systems. I don't think it ever was on any Linux (or maybe UNIX) system. The default was changed consciously from the installation by the administrators of those systems, for whatever reason. The user can change it to bash, ksh, zsh, whatever his soul desires. For reasons of portability that you mentioned yourself, the default SHELL used by many programs (e.g., make) is /bin/sh. That is what changed on Kfir's system, changed in a way that a user cannot override, and it turned out that as a result a utility so basic as echo did not implement any options (-n and -e are just about the only options echo has). I don't think it is expected of /bin/sh on a general-purpose system, frankly. You mentioned yourself that Kfir's makefile was autogenerated. It had /bin/sh, not bash, as its environment, and it still used echo -e -n. Now let's say Kfir is a normal user. He cannot change /bin/sh, he cannot change the Makefile, the only way out is to invoke whatever build procedure there is under an environment where SHELL=/bin/bash (*not* /bin/sh), and hope that a) the build procedure does not explicitly reset SHELL to /bin/sh somewhere, and b) that bash is indeed fully compatible with sh. I'd be hard pressed to conclude that the application is broken. By the way, FWIW bash is supposed to know when it is invoked as sh (see man bash for details). I just checked (on a Fedora system) that echo accepts options inside sh. I am not saying Debian did anything that was not within their rights. I think, however, that it is somewhat against the expectations of even an experienced UNIX/Linux user (and I gather that's not the exclusive audience of Ubuntu), and I wondered publicly what it might break. But there is a lesson here somewhere: a) don't use echo options in portable #!/bin/sh scripts; b) consider #!/bin/bash even for portable code (restricting it to systems with bash installed, of course). -- Oleg Goldshmidt | [EMAIL PROTECTED] | http://www.goldshmidt.org ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
