[H-GEN] What the...? Weird behaviour from bash

[Byron Ellacott]

On Sat, 7 Feb 1998, Jason Parker wrote:

> > ] [aj at azure ~]$ /bin/sh
> > ] [aj at azure ~]$ echo hello | cat >& /dev/null
> > ] hello
> > ] [aj at azure ~]$ /bin/bash
> > ] [aj at azure ~]$ echo hello | cat >& /dev/null
> > ] [aj at azure ~]$ exit
> IIRC, it's up to the shell to decide job execution order.  So, at a
> guess, I'd reckon that bash has some `optimal' method of execution.
> Or maybe you're just getting different results after just one (or a
> small number of) test(s)?  [You did do it more than once, right?  :)]
perhaps .. but, as the hello is not echoed at all for the /bin/bash
version of the command, it implies that only *one* job is executed
here .. a pipe is a pipe is a pipe.  Also, the position of the job
separator ('&') would give the second command as being /dev/null, and
so we can assume that '>&' is being considered one symbol.

Now, someone recently pointed out to me that bash, when invoked as
'sh', disables many of it's more advanced features, and acts
presakerly like the original bourne shell.  One is therefore inclined
to suspect that the difference lies in the way the `different' shells
interpret this symbol.  To the man pages!

Well, they came up with little information <sigh> so I'll try to fire
up a few memory cells.

'&>' means `redirect both stdout and stderr to', and is afaik a bash
extension.  It's also irrelevant here.

'>&' means `redirect to this fildes' .. as in 2>&1 .. however, given the
missing fildes, we can only postulate as to the behaviour of the
shells.  I would take it from the above to hazard the first to be
redirecting stdout to stdout, but wouldn't care to think what the
/dev/null part of that line might end up meaning.  In the second case,
however, it might be seen as redirecting stdout to a nonexistent file
descriptor, and hence producing no output whatsoever.

Of course, this is all speculation .. and can be tested without the
`cat' part of the command line, in theory .. (runs to other window)
Indeed it can.

Now, the interesting part here is that bash will produce the file
named after the '>&' symbol, making me inclined to believe it will
interpret the 'fildes' as being a file name, also, whereas sh will
merely think you're an idiot in providing it with an invalid fildes.

QED?

----------------------- HUMBUG General List --------------------------------
echo "unsubscribe general" | mail majordomo at humbug.org.au # To Unsubscribe