Re: GOTCHA in Ubuntu - broken shell
On 10/1/07, Bill McGonigle <[EMAIL PROTECTED]> wrote: >> What I'm saying is #!/bin/sh should run like #!/bin/sh. export >> VAR=value doesn't work in bourne shell. So if you put that in a bourne >> shell script with #!/bin/sh, then it should fail > > That seems to be the root cause of the problem, IMHO. Bash is > _supposed to_ run in POSIX/Bourne-shell mode when invoked as /bin/sh, > right? I think the root cause is that there isn't any "POSIX shell" or "Bourne shell" standard, in the way that we usually think of the word "standard". Even the Bourne shell evolved over time, although I don't know to what degree. Later on, just about everybody tweaked their shell at least a little bit (or maybe a lot). The POSIX "standard" reflects this, in its range of acceptable behavior. It can be argued that POSIX was more about inventing a standard that fit existing implementations, rather than the other way around. So there's nothing "standard" about the whole thing. bash takes it to an extreme, to be sure, but it's really just continuing the trend. So I guess my point is: Saying "#!/bin/sh should run like #!/bin/sh" is largely meaningless, because there is no agreed-upon definition for what "run like #!/bin/sh" means. Come to think of it, bash added features over time, too. So I guess what we really should be doing is putting #/bin/bash-3.1-CentOS-5-build-16.1 at the top of all our shell scripts. Right? > The man page says: >> When invoked as sh, bash enters posix mode after the startup files are read. I looked up the same thing last night. Looking at the man page, the *only* thing "POSIX mode" is reported to do is change the startup files bash uses. There's nothing in that doc about changing other behaviors. Whether that makes it a "feature" or simply a "documented bug" is a mostly semantic distinction. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On Oct 1, 2007, at 10:30, Tom Buskey wrote: > What I'm saying is #!/bin/sh should run like #!/bin/sh. export > VAR=value > doesn't work in bourne shell. So if you put that in a bourne shell > script > with #!/bin/sh, then it should fail That seems to be the root cause of the problem, IMHO. Bash is _supposed to_ run in POSIX/Bourne-shell mode when invoked as /bin/sh, right? It seems that lots of people are running #!/bin/sh and getting bash extensions to evaluate. If this didn't happen none of this would be an issue, the scripts would never have left the barn. The man page says: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interac- tive login shell, or a non-interactive shell with the -- login option, it first attempts to read and execute commands from /etc/ profile and ~/.profile, in that order. The --noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and exe- cute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read. What am I missing? -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On Mon, 2007-10-01 at 10:30 -0400, Tom Buskey wrote: > > Thank goodness environments have converged a > bit. /bin/perl, /bin/bash exist in Solaris, Linux, Cygwin, xBSD and > (I think) MacOSX. /bin/bash is present in OSX, but not in the default FreeBSD install or the default DragonFly BSD install. PC-BSD does include it, though, along with other heresies like a graphical interface by default and a KDE desktop. Dunno about NetBSD or OpenBSD, because I haven't had occasion to install either of those yet, but considering that OpenBSD still cares about performance on VAXen, I doubt very much that they'd include a RAM-sucking pig like bash by default. I've installed about 25 different operating systems for $dayjob in the past few months, and I have to say that my opinion of the useful niches for certain systems has shrunk considerably in the process. (Of all the non-Linux systems I installed, only PC-BSD had a GUI to add a new user, and it didn't even work right; sure, I can use adduser from the command line, but because every single one does adduser slightly differently, I spent an inordinate amount of time groveling through man pages, all to handle a task that the better systems did as part of the installation process, automatically. I've also found a surprising number of older systems that were unnecessarily difficult to install because the default installation pointed at update download sites that now hold updates for a later version; FreeBSD and Debian are the two major offenders here, where Ubuntu, despite being a much newer project, gets this right.) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: [ means test right? Maybe? (was: Re: GOTCHA in Ubuntu - broken shell)
On 10/1/07, Flaherty, Patrick <[EMAIL PROTECTED]> wrote: >> FYI, the correct operator is = and == is an extension of bash. == >> should not be used. > > I thought everything in those brackets was just an argument to test. It is. Sort of. Except that /usr/bin/test -- and it's alias, /usr/bin/[ -- is also a shell built-in for many shells, bash among them. So if you're running bash, you're not using /usr/bin/test, you're using a bash feature. In the original Bourne shell, a lot of things which are shell built-in's were external programs. Those include test, [, echo, which, kill, and pwd. (This is not an exhaustive list.) In bash, you can use the "enable" built-in to list and control built-in commands. (To really mess things up, try "enable -n enable", which disables the "enable" command. ;-) ) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: [ means test right? Maybe? (was: Re: GOTCHA in Ubuntu - broken shell)
On 10/1/07, Jeffry Smith <[EMAIL PROTECTED]> wrote: > > On 10/1/07, Tom Buskey <[EMAIL PROTECTED]> wrote: > > > > > Here's the relevant bash (3.2.9) man page on Fedora 7: > > > > > > string == pattern > > True, if string matches pattern. Any part of pattern > can > > be > > quoted to cause it to be matched as a string. With a > > successful > > match to a pattern, the .sh.match array variable will > > contain > > the match and sub-pattern matches. > >string = pattern > > Same as == above, but is obsolete. > > > > And Solaris (bash 3.00.16): > > string1 == string2 > > True if the strings are equal. = may be used in place > > of == for strict POSIX compliance. > > > > Sounds like dash isn't fully cooked. == is used & works in ksh, bash > and > > sh. > > > Actually, dash is fully cooked - note that those are bash pages. Note > specifically on Solaris: "= may be used in place of == for strict > POSIX compliance." > > I don't have access to the dash man page right now, but the Ubuntu > reason for dash is that it's Posix compliant. "==" may work, but > you're depending on non-standard (as in de jure) behavior. > > Not saying I agree with the decision, merely pointing out saying that > "dash isn't fully cooked" when it supports POSIX when in POSIX mode, > and bash for some reason accepts other things that are not specified > by POSIX is not a good arguing point. Ah, I missed something. ksh (on Fedora) says: string = pattern Same as == above, but is obsolete. So POSIX says use = and ksh says = is obsolete. Ugh. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On October 01, 2007, Tom Buskey sent me the following: > If you want bash or ksh, use #!/bin/bash or #!/bin/ksh. If it doesn't exist > in /bin, put it there where it belongs. Coming from a primarily FreeBSD background, I'm against the idea of putting bash in /usr/bin. In my world, /usr is for programs included with the operating system distribution, and /usr/local is for locally added programs, like bash. For a solution to the pathing problem, usually in the case of perl, I've seen people use "#!/usr/bin/env perl" which will find a perl in $PATH and execute it, though this breaks for people who like to give command line arguments as part of a #! on some OSes. A little searching turns up a pretty good Wikipedia page on the subject: http://en.wikipedia.org/wiki/Shebang_(Unix) -- Chip Marshall <[EMAIL PROTECTED]> http://kyzoku.2bithacker.net/ GCM/IT d+(-) s+:++ a26>? C++ UB$ P+++$ L- E--- W++ N@ o K- w O M+ V-- PS+ PE Y+ PGP++ t+@ R@ tv@ b++@ DI D+(-) G++ e>++ h>++ r-- y? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: [ means test right? Maybe? (was: Re: GOTCHA in Ubuntu - broken shell)
On 10/1/07, Tom Buskey <[EMAIL PROTECTED]> wrote: > > Here's the relevant bash (3.2.9) man page on Fedora 7: > > > string == pattern > True, if string matches pattern. Any part of pattern can > be > quoted to cause it to be matched as a string. With a > successful > match to a pattern, the .sh.match array variable will > contain > the match and sub-pattern matches. >string = pattern > Same as == above, but is obsolete. > > And Solaris (bash 3.00.16): > string1 == string2 > True if the strings are equal. = may be used in place > of == for strict POSIX compliance. > > Sounds like dash isn't fully cooked. == is used & works in ksh, bash and > sh. > Actually, dash is fully cooked - note that those are bash pages. Note specifically on Solaris: "= may be used in place of == for strict POSIX compliance." I don't have access to the dash man page right now, but the Ubuntu reason for dash is that it's Posix compliant. "==" may work, but you're depending on non-standard (as in de jure) behavior. Not saying I agree with the decision, merely pointing out saying that "dash isn't fully cooked" when it supports POSIX when in POSIX mode, and bash for some reason accepts other things that are not specified by POSIX is not a good arguing point. jeff ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: [ means test right? Maybe? (was: Re: GOTCHA in Ubuntu - broken shell)
On 10/1/07, Flaherty, Patrick <[EMAIL PROTECTED]> wrote: > > > =>The band-aid, by the way, was that "=" instead of "==" works. > > =>(And how ugly is THAT? And how do you explain that to a student?) > > > > FYI, the correct operator is = and == is an extension of bash. == > should > > not be used. > > > > I thought everything in those brackets was just an argument to test. The > = or == shouldn't be dependant on your shell, but on your coreutils > version. > > However, I tested it. > [EMAIL PROTECTED]:~/hack$ cat test.dash > #!/bin/dash > > t="X" > > if [ "$t" == "X" ]; then > echo $t; > else > echo "Not X" > fi > [EMAIL PROTECTED]:~/hack$ dash test.dash > [: 9: ==: unexpected operator > Not X > [EMAIL PROTECTED]:~/hack$ bash test.dash > X > > ...and now my world is turned upside down. > > Anyone know why this works that way? It sounds like dash is breaking lots of people's assumptions. I do a man test on Fedora 7 and it does not show ==. On Solaris 10, it has an example of == for csh. Man bash & ksh on Fedora 7 shows == for both. bash on Solaris shows == for bash, but nothing for ksh. And of course, [ is a builtin whereas test is /bin/test. Linux has /usr/bin/[ so you could be explicit, but most shells substitute their builtin [. Here's the relevant bash (3.2.9) man page on Fedora 7: string == pattern True, if string matches pattern. Any part of pattern can be quoted to cause it to be matched as a string. With a successful match to a pattern, the .sh.match array variable will contain the match and sub-pattern matches. string = pattern Same as == above, but is obsolete. And Solaris (bash 3.00.16): string1 == string2 True if the strings are equal. = may be used in place of == for strict POSIX compliance. Sounds like dash isn't fully cooked. == is used & works in ksh, bash and sh. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
[ means test right? Maybe? (was: Re: GOTCHA in Ubuntu - broken shell)
> =>Another example. This one is [was] my "favorite"; I think it was
> =>the first one to bork on me. The error message was [is] so obscure
> =>that for the past year I've lived with band-aiding each "if"
> =>statement one at a time, just to have something which works.
> =>(One uses "if" statements much more frequently than slicing.)
> =>In bash:
> => $ if [ "${breakfast}" == "spamandeggs" ]; then
> => > echo "yummy"
> => > fi
> => yummy
> => $
> =>In dash:
> => $ if [ "${breakfast}" == "spamandeggs" ]; then
> => > echo "yummy"
> => > fi
> => [: 11: ==: unexpected operator
> => $
> =>
> =>How ugly and unhelpful is that?
> =>
> =>The band-aid, by the way, was that "=" instead of "==" works.
> =>(And how ugly is THAT? And how do you explain that to a student?)
>
> FYI, the correct operator is = and == is an extension of bash. ==
should
> not be used.
>
I thought everything in those brackets was just an argument to test. The
= or == shouldn't be dependant on your shell, but on your coreutils
version.
However, I tested it.
[EMAIL PROTECTED]:~/hack$ cat test.dash
#!/bin/dash
t="X"
if [ "$t" == "X" ]; then
echo $t;
else
echo "Not X"
fi
[EMAIL PROTECTED]:~/hack$ dash test.dash
[: 9: ==: unexpected operator
Not X
[EMAIL PROTECTED]:~/hack$ bash test.dash
X
...and now my world is turned upside down.
Anyone know why this works that way?
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On 10/1/07, Ben Scott <[EMAIL PROTECTED]> wrote: > > On 10/1/07, Tom Buskey <[EMAIL PROTECTED]> wrote: > > Scripting non-bourne shell stuff with #!/bin/sh at the top *should* > break. > > Ah, yes, maximum pain as a design goal. :-( What I'm saying is #!/bin/sh should run like #!/bin/sh. export VAR=value doesn't work in bourne shell. So if you put that in a bourne shell script with #!/bin/sh, then it should fail. If you want it to succeed, use a shell that accepts that syntax, such as #!/bin/bash or #!/bin/ksh. I've seen scripts that start w/o #!/bin/sh by people with a default csh. They run ok in their environment, but someone running bash breaks them. They're coding csh so #!/bin/csh should be at the top. It'd expect csh scripts to fail if #!/bin/sh was at the top because sh runs bourne shell. > If you want bash or ksh, use #!/bin/bash or #!/bin/ksh. > > What about an extension feature that exists in more than one > implementation, but is not part of POSIX? What about the "range of acceptable implementations" problem of the > POSIX standard that Fran Fadden pointed out? I don't think I can address this so I won't. > If it doesn't exist in /bin, put it there where it belongs. > > So now shell scripts are totally unportable. No, #!/bin/sh is bourne shell. /bin/bash is bash. If you need your bash script to work on, say SunOS or Solaris 7, install /bin/bash so it will work. So maybe bash scripts are not portable, but they never really were. Maybe they are on linux where #!/bin/bash always exists. Look at perl. Nowadays it is on most systems. It used to have to be added. It was in /bin, /usr/local/bin, /opt/sfw/bin. When you go on a new system, you can't ensure that all the modules your script needs are installed so you have to add them. Maybe you're on Solaris 8 with perl 5.0003 and perl 5.8 was installed in /usr/local/bin with all the modules. > I've been shell scripting for awhile on multiple OSen. > > Yah, and it sucks. Linux should aim to succeed where other *nixes > fail, and not suck. I agree too. I don't think making /bin/sh run bashism would be any different from linking /bin/sh to /bin/csh. My point is that expecting #!/bin/sh to act like bash or ksh or csh is wrong. It's like expecting grape juice to taste like wine. I don't want a sequel to the Unix Wars. Who does? Thank goodness environments have converged a bit. /bin/perl, /bin/bash exist in Solaris, Linux, Cygwin, xBSD and (I think) MacOSX. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On 10/1/07, Tom Buskey <[EMAIL PROTECTED]> wrote: > Scripting non-bourne shell stuff with #!/bin/sh at the top *should* break. Ah, yes, maximum pain as a design goal. :-( > If you want bash or ksh, use #!/bin/bash or #!/bin/ksh. What about an extension feature that exists in more than one implementation, but is not part of POSIX? What about the "range of acceptable implementations" problem of the POSIX standard that Fran Fadden pointed out? > If it doesn't exist in /bin, put it there where it belongs. So now shell scripts are totally unportable. > I've been shell scripting for awhile on multiple OSen. Yah, and it sucks. Linux should aim to succeed where other *nixes fail, and not suck. I don't want a sequel to the Unix Wars. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
Scripting non-bourne shell stuff with #!/bin/sh at the top *should* break. Even if /bin/sh is a link to bash/ksh that changes its behavior based on the link. If your code breaks, shame on you. You shouldn't use bashisms/kshisms in #!/bin/sh. If you want bash or ksh, use #!/bin/bash or #!/bin/ksh. If it doesn't exist in /bin, put it there where it belongs. I've been shell scripting for awhile on multiple OSen. SunOS (not Solaris) had /bin/csh as the default. Ultrix had an older version of bourne shell that didn't do functions. /bin/sh5 had functions. Try writing a script with functions that works on Ultrix, SunOS, Solaris, HP-UX, OSF/1, Irix and Linux. Some versions of Linux use PD ksh as /bin/ksh which is missing stuff in true AT&T ksh as on Solaris, HP, Irix, etc. SunOS didn't ship with ksh; you had to install it ($$). Solaris before 8 didn't have /bin/bash. At least with shell scripting /bin/sh is always there. Try perl, python, tcl/tk. /bin? /usr/bin, /usr/local/bin, some site dependent place? Every OS has had a different place. This is similar to C coding "All the world's a VAX" where 32 bit code broke when it went 64 bits due to assuming 32 bit rollovers. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
Ben Scott wrote: > On 9/29/07, Tyson Sawyer <[EMAIL PROTECTED]> wrote: >> If you say '/bin/sh' then you should speak '/bin/sh'. >> If you are speaking '/bin/bash', then you should say, '/bin/bash'. > > It gets ugly in the other direction, too, BTW. Some people fall the > habit of just putting "#!/bin/bash" at the top of every shell script > they write, even those that do not use bash-specific features. If > those shell scripts then go to a system which has *a* Bourne-like > shell but not bash, they fail, because bash isn't available, even > though another shell (which would have worked) is. > > And then we can get into extension which are present in multiple > shells (say, bash and zsh) but not a basic, POSIX-compliant, > Bourne-like shell. What do you do *then*? It gets even worse still... Bash changes to "posix mode" when invoked as /bin/sh. This means that there is at least a possibility that you've used something in the gray area between bash's "posix" implementation and what would work if you invoked the shell as "bash". The problem is that the "standard" defines a range of acceptable implementations, and any shell that falls in that range is a "posix" shell. I am not familiar with dash, but I would be quite surprised if even dash implemented only that part of the language that was *required* to be implemented in all posix shells, with the most restrictive limits in all cases where posix specified a choice. This means that even if you doctor all your scripts to work with both bash and dash, there is no guarantee that the next implementation that comes along won't break something else. This is why, from a user's point of view, I've always liked the bash philosophy of including syntax from "historical" implementations so that users don't *have* to retrain themselves. The compiler folks faced this problem years ago, by providing an option (ok, *lots* of options) to bitch when a program uses a construct that, while conforming to the language definition, is not required to be present in every implementation of the language. Maybe it is time for something like this in the shell too, or a "lint" version of the shell, perhaps. Meanwhile, I agree with the sentiment that "bash" (one version or another) should be the "standard" shell on Linux distros and I am disappointed that Ubuntu (or *any* major Linux distro) thinks so little of their users as to stick with this decision. It ends up reflecting poorly on the Linux community as a whole. Fran ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
Ben Scott wrote: > > Personally, I think the right thing to do is make bash the de facto > standard on all *nix systems. We don't need this kind of headache. > But others obviously disagree. Entropy wins again. But then, it > always does. > Always? Man, there ought to be a law :) -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On 9/29/07, Tyson Sawyer <[EMAIL PROTECTED]> wrote: > If you say '/bin/sh' then you should speak '/bin/sh'. > If you are speaking '/bin/bash', then you should say, '/bin/bash'. It gets ugly in the other direction, too, BTW. Some people fall the habit of just putting "#!/bin/bash" at the top of every shell script they write, even those that do not use bash-specific features. If those shell scripts then go to a system which has *a* Bourne-like shell but not bash, they fail, because bash isn't available, even though another shell (which would have worked) is. And then we can get into extension which are present in multiple shells (say, bash and zsh) but not a basic, POSIX-compliant, Bourne-like shell. What do you do *then*? Personally, I think the right thing to do is make bash the de facto standard on all *nix systems. We don't need this kind of headache. But others obviously disagree. Entropy wins again. But then, it always does. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On Friday, Sep 28th 2007 at 14:53 -, quoth Bill Sconce:
=>___
=>Another example. This one is [was] my "favorite"; I think it was
=>the first one to bork on me. The error message was [is] so obscure
=>that for the past year I've lived with band-aiding each "if"
=>statement one at a time, just to have something which works.
=>(One uses "if" statements much more frequently than slicing.)
=>In bash:
=> $ if [ "${breakfast}" == "spamandeggs" ]; then
=> > echo "yummy"
=> > fi
=> yummy
=> $
=>In dash:
=> $ if [ "${breakfast}" == "spamandeggs" ]; then
=> > echo "yummy"
=> > fi
=> [: 11: ==: unexpected operator
=> $
=>
=>How ugly and unhelpful is that?
=>
=>The band-aid, by the way, was that "=" instead of "==" works.
=>(And how ugly is THAT? And how do you explain that to a student?)
FYI, the correct operator is = and == is an extension of bash. == should
not be used.
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On 9/28/07, Bill Sconce <[EMAIL PROTECTED]> wrote: > (And remember to not trust Ubuntu. They don't think things through > to the consequences. They don't listen, either. See below.) How about the consequences of using the syntax of one language and asking the shell/interpreter/compiler of a different one to run it? Bill, I have to disagree with you on this one. If you say '/bin/sh' then you should speak '/bin/sh'. If you say '/usr/bin/python' then you should speak '/usr/bin/python'. If you are speaking '/bin/bash', then you should say, '/bin/bash'. Don't use bash syntax in a script that is configured to be run by /bin/sh. of course, if dash is failing on correct sh syntax, then Ubuntu screwed up and the above comments don't apply. Cheers! Ty -- Tyson D Sawyer I prefer dangerous freedom over peaceful slavery. -- Thomas Jefferson ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell [FLAMEBAIT]
Bill Sconce wrote: > Arrogant. Unbelievable. The side effects were reported during beta > and still the developers did this. > Clearly, they made a decision, and you (and a number of others) just don't like like it. The developer's justification appears to be "because I think its best this way" (My observation is conscientious developers would have stated their reasons and let it get hashed out in the various forums.) On the other hand, they may be trying to force application developers to fix their mistakes - this invariable turns out about as successful as forcing Unix programmers to not use null-terminated strings. Linux philosophy says you have a choice of another distribution. Open Market philosophy says you can use another product (for the most part: Windows, Apple, or BSD). Welcome to Open Source, where its the developers fault instead of some nebulous company that hides behind lawyers. --Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On Fri, 28 Sep 2007 15:31:13 -0400 Sarunas <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > Bill Sconce wrote: > > Hi, all - > > You may know this: Ubuntu's default shell isn't bash. > > Only partially true. Installer/dpkg asks you whether you want dash > (i.e./bin/sh -> /bin/dash symlink). Yike. This makes it worse. I don't remember answering any such question. And I've done dozens of Ubuntu installs. And I see nothing about an install-time option in the otherwise lengthy thread about this bug report at https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 . But sure enough, if I type at a root prompt: dpkg-reconfigure dash up comes a CURSES window: Ubuntu Configuration | Configuring dash | || | Bash is the default /bin/sh on a Debian system. However, | | since our policy requires that all shell scripts using| | /bin/sh to be POSIX compliant, any shell that conforms| | to POSIX can serve as /bin/sh. Since dash is POSIX| | compliant, it can be used as /bin/sh. You may wish to do | | this because dash is faster and smaller than bash.| || | Install dash as /bin/sh? | || | | | ^| It has to be possible that I saw this at install time. (Although the default clearly IS dash.) What makes it worse: o Now the user's been made complicit in causing the problem o The "you may wish...faster and smaller" is a clear recommendation o The "since our policy" may take care of THEIR scripts, but it leaves users exposed to every bash script ever written, both their own and every bash script supplied by every third party, including hosts of packages in upstream standard Debian. Arrogant. Unbelievable. The side effects were reported during beta and still the developers did this. Nevertheless, thanks, Sarunas. Presumably I "asked" for this trouble when I installed Ubuntu; even if I don't remember clicking "Yes" it's almost certain that I would have. I would have read that as promising that dash was compatible with bash, only smaller and faster. Who wouldn't? (Who here didn't? :) ON THE OTHER HAND: Even now, a year later, typing as root "dpkg-reconfigure dash" and selecting * * UNDOES THE DAMAGE * * !! I just did so. Now /bin/sh -> /bin/bash ! And my scripts work again. This is a WHOLE lot better than having to find and change hundreds of script headers. (Which would only have taken care of my own scripts in any case. And not the next script in some downloaded package.) And just now I'm wondering: how many of the obscure "./configure | make | make install" problems I've encountered have been due to dash? EVERY "make" problem is obscure... having a broken /bin/sh can only make things more difficult.) Fixed. Hurrah! Now all we have to do is remember that we "may wish to do this" NOT!! in future Ubuntu installs... Thanks again, Sarunas! Brilliant catch. -Bill P.S. I recommend reading that entire launchpad thread -- it's like reading Microsoft's opinions of THEIR users' troubles... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On 9/28/07, Bill McGonigle <[EMAIL PROTECTED]> wrote: > So who has a tool that scans your scripts for bash-isms? grep -E . /path/to/my-script.sh ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
Bill McGonigle <[EMAIL PROTECTED]> writes: > So who has a tool that scans your scripts for bash-isms? "dash -n " -- perhaps? Regards, --kevin -- GnuPG ID: B280F24E God, I loved that Pontiac. alumni.unh.edu!kdc -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
On Sep 28, 2007, at 14:53, Bill Sconce wrote: > /bin/sh: Syntax error: Bad substitution I ran into this earlier, Oracle distributes: #!/bin/sh scripts with their installers that use bash functions and bork on Solaris's sh with substitutions. export FOO=bar even fails. They also hardcode in the developer's home directory in their start scripts, which you have to fix to even star their database product. This was reported over two years ago and the version you download today still has vikrkuma's home directory hard-coded! Compare that with Ubuntu. :) So who has a tool that scans your scripts for bash-isms? -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: GOTCHA in Ubuntu - broken shell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Sconce wrote: > Hi, all - > > You may know this: Ubuntu's default shell isn't bash. > Only partially true. Installer/dpkg asks you whether you want dash (i.e./bin/sh -> /bin/dash symlink). Sarunas Burdulis Dartmouth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG/VaBVVkpJ1MUn+YRAk+fAJ0QUPpEnB5tkrBYWM8ZM4y+fUxkNQCaAp06 mkwzTgGRlAUEGcmVbEzzGHs= =IGzt -END PGP SIGNATURE- ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
GOTCHA in Ubuntu - broken shell
Hi, all -
You may know this: Ubuntu's default shell isn't bash.
[I grepped to see if anyone has mentioned the issue here
before; it seems not. Apology if my post is a duplicate.]
For months I've been seeing difficult-to-understand problems in
shell scripts: syntax errors, "bad substitution"; weird stuff.
Not reproducible. Dozens of hours lost, trying workarounds.
I am not making this up.
Did you know that Ubuntu's /bin/sh, which used to point to bash
(as it does and always has on most Linux distributions), was
changed to "dash"? (Subsequent to LTS/6.06, evidently.)
True, dash mostly works. Where it doesn't work... Arrgh.
I have countless scripts which begin with "#!/bin/sh". Moreover,
when I've taught "Introduction To Scripting" I've always suggested
that scripts begin with "#!/bin/sh", since that matches what
students will see in any distro's installed scripts. (I know,
I know, I've ALWAYS known that /bin/sh *could* be other than bash.)
"#!/bin/sh" has been "accepted practice" on Linux. Always. Even in
Ubuntu.
BUT.
Ubuntu made a change. Many users therefore may have scripts which
had worked fine since the days of Yggdrasil (as in my case), and
which indeed worked fine through several releases of Ubuntu, but
which for the last year have been causing transient, hard-to-find,
"WTF?" problems.
Solution: not difficult. Make your shebang line be "#!/bin/bash".
(And remember to not trust Ubuntu. They don't think things through
to the consequences. They don't listen, either. See below.)
Hope this helps someone.
-Bill
___
Details; the light finally dawned just this morning. A script
fragment which had worked for years (interactively, in terminal
windows) seemed to suddenly break when used in a script. It
involved slicing. Interactively (in bash):
$ breakfast="spamandeggs"
$ echo "${breakfast:0:4}"
spam
$
In dash (i.e., in a script which starts with #!/bin/sh on Ubuntu):
$ breakfast="spamandeggs"
$ echo "${breakfast:0:4}"
/bin/sh: Syntax error: Bad substitution
$
The message is correct, of course: it's the shell which doesn't like
my code, and it's /bin/sh which is the shell. That's the tipoff.
>From there,
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 2007-01-01 17:30 /bin/sh -> dash
$
** NOT bash! **
It had never occurred to me THAT A DISTRO COULD DO SOMETHING AS
DANGEROUSLY REGRESSIVE as change the default shell to something
not backward compatible.
___
Another example. This one is [was] my "favorite"; I think it was
the first one to bork on me. The error message was [is] so obscure
that for the past year I've lived with band-aiding each "if"
statement one at a time, just to have something which works.
(One uses "if" statements much more frequently than slicing.)
In bash:
$ if [ "${breakfast}" == "spamandeggs" ]; then
> echo "yummy"
> fi
yummy
$
In dash:
$ if [ "${breakfast}" == "spamandeggs" ]; then
> echo "yummy"
> fi
[: 11: ==: unexpected operator
$
How ugly and unhelpful is that?
The band-aid, by the way, was that "=" instead of "==" works.
(And how ugly is THAT? And how do you explain that to a student?)
Some background.
"Awww, c'mon. It couldn't be the *shell*."
"They couldn't have been that stupid."
They could.
"Awww. I couldn't have been stupid enough to believe that
it was me, for over a year."
I could...
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463
Bug #61463, first reported on 2006-09-20 by Egil Hasting
Bug description
The scripting capability between bash and dash are not
equal, which could break scripts that today relies on bash
( #!/bin/sh -> /bin/bash), i tracked down this problem
with cedega on edgy, and was able to get it working again
by forcing the script to use #!/bin/bash (instead of /bin/sh)
__
Tom Bruno wrote on 2006-09-27:
This is a pretty large scale problem. I'm seeing scripts breaking
all over the place. and strange errors about bad interpreters and
such since this change.
__
Jason Straight (LeeJunFan) wrote on 2006-09-29:
Yeah, I agree, I even had some installation scripts fail when
dash replaced bash during apt-get dist-upgrade. As well as some
LSB scripts. It was an unholy mess.
__
anthony baxter wrote on 2006-10-17:
Please reverse this change before edgy final. It's caused
massive breakage for me - for instance, the intel compiler was
utterly broken. It relied on 'export -n' and 'exec -a' working.
I'm almost tempted to remove dash with dpkg -r and live with
the apt-get complaints.
This is a huge mistake - it's broken all manner of things
for me, and I suspect that it will end up being a support
nightmare once edgy final is released to the world.
Yes, people shouldn't have assumed that
