Comments on: bourne shell == line noise

Question: bourne shell == line noise

Armitage Shanks — Thu, 22 Mar 2007 15:31:56 -0800

Please help me understand what this OS X shell script is doing.

On OS X 10.4, the 'cd' command is a shell script in /usr/bin/cd:

#!/bin/sh
${0##*/} ${1+"$@"}

Can someone explain it to me?

By: edd

edd — Thu, 22 Mar 2007 15:38:34 -0800

cd's a builtin command in the shell. It's calling the builtin sh cd command with the argument. Presumably it's there for use when you're not in a shell environment to cd inside.

By: edd

edd — Thu, 22 Mar 2007 15:47:50 -0800

I should clarify that the first argument is the name of the script, so this is the same script that handles fg, alias and other otherwise-builtin commands - you can see that it just repeats what you put in if you copy it elsewhere, put an 'echo' in before it, and run it from the other location.

Also, on poking more knowledgeable types the ##*/ is responsible for eliminating the path if you try to put one in, so /usr/bin/cd gets reduced down to just cd. Not too sure about the nature of the thing that provides the arguments.

By: donpardo

donpardo — Thu, 22 Mar 2007 15:48:12 -0800

By: Aidan Kehoe

Aidan Kehoe — Thu, 22 Mar 2007 15:53:51 -0800

edd, yes,

cd's a builtin command in the shell.

and indeed, it has to be—the script is puzzling, since to my knowledge it can't change the working directory of its parent process without using some application-specific IPC to do so, and as such, what it does is start a new shell, change that shell's current directory to the specified directory, then exit from it, returning to the parent shell, with the original working directory. Useless.

By: Aidan Kehoe

Aidan Kehoe — Thu, 22 Mar 2007 15:55:44 -0800

I should clarify that the first argument is the name of the script, so this is the same script that handles fg, alias and other otherwise-builtin commands - you can see that it just repeats what you put in if you copy it elsewhere, put an 'echo' in before it, and run it from the other location.

Ah, okay, so it may have been linked to cd because someone thought it sensible to provide shell script versions of all the built-in commands, even where that made no sense.

By: edd

edd — Thu, 22 Mar 2007 15:59:33 -0800

Ah yes, good point, but as donpardo's link points out it can be used to check if you can cd into a directory, even if it doesn't actually get the parent there.

Another knowledgeable type tells me that the noise in the second argument is to help deal with no argument. It stops attempts to do a 'cd ""' if you don't give a second argument in some cases, and just does the 'cd' instead.

By: vacapinta

vacapinta — Thu, 22 Mar 2007 16:00:29 -0800

Can't it be used to see if cd'ing to a specific directory is possible (by branching on the return code) before attempting to cd to that directory?

By: Freaky

Freaky — Thu, 22 Mar 2007 16:08:12 -0800

${0##*/} -> $0 expands to the name of the script, ## removes the largest prefix pattern, and */ tells it to match until the last / in the string: this turns "/usr/bin/cd" into "cd".

${1+"$@"} -> test if $1 (first argument) is unset, if not, expand the argument list ($@) without field spliting (so you don't expand "cd /foo\ bar/" into "cd '/foo' 'bar/'")

man sh :)

By: dmd

dmd — Thu, 22 Mar 2007 16:51:57 -0800

It may shed some light on this situation if one knows that /usr/bin/alias, bg, cd, command, fc, fg, getopts, hash, jobs, read, type, ulimit, umask, unalias, and wait ALL look like this on OSX:



#!/bin/sh

# $FreeBSD: src/usr.bin/alias/generic.sh,v 1.1 2002/07/16 22:16:03 wollman Exp $

# This file is in the public domain.

${0##*/} ${1+"$@"}

By: Armitage Shanks

Armitage Shanks — Thu, 22 Mar 2007 17:00:21 -0800

It may shed some light on this situation if one knows that /usr/bin/alias, bg, cd, command, fc, fg, getopts, hash, jobs, read, type, ulimit, umask, unalias, and wait ALL look like this on OSX:

Interesting. It appears that none of these files exist in 10.3.

Here's a checkin I found for the file generic.sh on FreeBSD that may explain it (it confuses me even more, to be honest):

Use the "builtin" shell function to make sure that the requested
command is handled as a shell function. This avoids the following
peculiar behaviour when /usr/bin is on a case-insensitive filesystem:
# READ foo
(... long pause, depending upon the amount of swap space available ...)
sh: Resource temporarily unavailable.

By: cmiller

cmiller — Thu, 22 Mar 2007 17:03:44 -0800

cmiller@calliope:~ $ /usr/bin/cd /tmp cmiller@calliope:~ $
Indeed, what a strange little program.

By: Armitage Shanks

Armitage Shanks — Thu, 22 Mar 2007 17:16:09 -0800

Damn, this gets weirder all the time:

$ which cd
/usr/bin/cd
$ which CD
/usr/bin/CD
$ cd
$ CD
/usr/bin/CD: fork: Resource temporarily unavailable

If I edit /usr/bin/cd and add an "echo FOO" to it, when I execute "CD" (in caps), it goes into an infinite loop printing "FOO" until it runs out of processes. So it seems like it's not even preventing the problem it was meant to. Wtf.

By: Armitage Shanks

Armitage Shanks — Thu, 22 Mar 2007 17:23:47 -0800

Actually, it seems to *introduce* the problem. On 10.3, if you try to run any of the builtins in caps, i.e.

CD
ALIAS
UNALIAS
etc

you just get "command not found". On 10.4, they all eventually run out of resources because the shell script version is presumably invoking itself recursively.

By: Freaky

Freaky — Thu, 22 Mar 2007 19:45:00 -0800

Yes, that's why the builtin function was added to it; builtin lookup is case-sensitive, so if filename lookup isn't, and you don't use the same case as the builtin to call the script, you get stuck in a loop as it tries to run $0. Explicitly telling the shell to use a builtin fixes this:

#!/bin/sh # $FreeBSD: src/usr.bin/alias/generic.sh,v 1.1.16.1 2005/11/04 18:21:37 cperciva Exp $ # This file is in the public domain. builtin ${0##*/} ${1+"$@"}

You crazy kids and your case-insensitive filesystems, you'll get us all killed!

By: flabdablet

flabdablet — Thu, 22 Mar 2007 19:53:41 -0800

I still don't understand why



${1+"$@"}

works. I mean, it clearly does, but all the sh and bash manuals I've ever seen say that the proper syntax for this should be



${1:+"$@"}

Is the first form just a terribly-old-skool version of the second?

By: Armitage Shanks

Armitage Shanks — Thu, 22 Mar 2007 20:00:21 -0800

Yes, that's why the builtin function was added to it;

Ah yes, I missed that, scratch my last two comments.

OK, so the only thing I'm not clear on is why /usr/bin equivalents for all these builtins (alias, bg, cd, command, fc, fg, getopts, hash, jobs, read, type, ulimit, umask, and unalias) were added in the first place.

By: Freaky

Freaky — Fri, 23 Mar 2007 11:11:24 -0800

"all the sh and bash manuals I've ever seen say that the proper syntax for this should be

${1:+"$@"}

Is the first form just a terribly-old-skool version of the second?"

Nope; it changes the behavior wrt null arguments, allowing for the expansion of empty strings. From sh(1):

${parameter:+word} Use Alternate Value. If parameter is unset or null, null is substituted; otherwise, the expansion of word is substituted. In the parameter expansions shown previously, use of the colon in the format results in a test for a parameter that is unset or null; omission of the colon results in a test for a parameter that is only unset.

You can see this behavior on a simple script like:

#!/bin/sh ruby -e 'p ARGV' ${1+"$@"} ruby -e 'p ARGV' ${1:+"$@"}

When ran with ./foo.sh ' bla you get:

["", "bla"] []

-- the second doesn't get expanded because with the colon, there's nothing to distinguish an empty (null) argument and no argument (unset).

As for their reason for existance, check the CVS logs: they're required by POSIX. Well, that's why they're in FreeBSD (and by proxy why they're in MacOS X); why they're in POSIX I don't know ;)

By: flabdablet

flabdablet — Sat, 24 Mar 2007 18:20:31 -0800

Thanks for that, freaky. You'd think I would have learned by now to read the sh manual with a fine tooth comb :-)

Okay. So ${1+"$@"} means "if argument 1 is set to anything at all, substitute all arguments individually quoted".

Then, because this happens inside an unquoted $1 expansion, the resulting value will be word-split. But because "$@" generates individually quoted values, word-splitting will only occur on the boundaries between those quoted values; in effect, the expansion of the substituted $1 will be all arguments, individually quoted.

So why would anybody use this convoluted test-and-substitute construction instead of a bare "$@"? Can you think of an argument list that would make



#!/bin/sh

ruby -e 'p ARGV' ${1+"$@"}

ruby -e 'p ARGV' "$@"

print two different output lines? I haven't been able to find one.

By: Freaky

Freaky — Sat, 24 Mar 2007 19:56:08 -0800

Pass; my reading of the manpage and tests suggest that indeed they're equivilent. The scripts are pretty much utterly useless anyway, so I guess useless tests within them are to be expected ;)

Maybe it's defensive, in case of a shell which doesn't expand "$@" properly in the zero-arguments case.

Asking on a mailing list may get more detail. *someone* on freebsd-*@freebsd.org probably knows ;)