Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^3: Running Under Some Shell

by rubasov (Friar)
on Feb 25, 2010 at 11:18 UTC ( #825274=note: print w/replies, xml ) Need Help??

in reply to Re^2: Running Under Some Shell
in thread Running Under Some Shell

I'd be surprised if the gubbin actually worked on csh.
Oh sorry. I wanted to refer to another gubbin, namely the second example in perlrun, that's the "more baroque" in the OP.

Perhaps the ${1+"$@"} is just a piece of cargo cult.
Exactly the same thought here.

Replies are listed 'Best First'.
Re^4: Running Under Some Shell
by JavaFan (Canon) on Feb 25, 2010 at 12:44 UTC
    Oh sorry. I wanted to refer to another gubbin, namely the second example in perlrun, that's the "more baroque" in the OP.
    Ah, you mean the
    eval '(exit $?0)' && eval 'exec perl -wS $0 ${1+"$@"}' & eval 'exec /usr/bin/perl -wS $0 $argv:q' if $running_under_some_shell;
    Let me try to explain. First, since "eval" is valid Perl, and so are the & and && operators, Perl will never execute any of it, because $running_under_some_shell is false.

    $?0 is special csh construct, returning 1 if the current filename is known, 0 otherwise. $? is the exit status of the most recent pipeline in sh. Since (exit $?0) is executed in a subshell (due to the parens), and from a file, eval '(exit $?0)' will return 0 in sh, but 1 in csh. This means, the eval 'exec perl -wS $0 ${1+"$@"}' is only executed by sh. But when executed by sh, sh will not see anything else of the file.

    Which leaves use with & eval 'exec /usr/bin/perl -wS $0 $argv:q'. I do not quite know how csh parses that - I can only assume csh allows a "null command" - which is then put in the background. Then it executes /usr/bin/perl -wS $0 $argv:q. We already know the meaning of the -wS $0 part. $argv is a variable holding all the arguments to the program. The :q is a modifier, quoting all the arguments (just like "$@" does in sh).

Re^4: Running Under Some Shell
by dupuy (Initiate) on Jun 29, 2013 at 22:11 UTC

    The use of ${1+"$@"} is a bit of a cargo cult thing these days, but I can remember the reason for it, and it's not unthinkable that it is still needed on the kinds of platforms where the rest of the gubbins are necessary.

    Early versions of /bin/sh (this is not going back to V7; it was present in 4BSD and probably into the 1990s on many flavors of Unix - but not Linux) did not do the right thing when there were no arguments to be quoted. If you used "$@" when there were no arguments, this was replaced by an empty string - rather than by nothing at all. Needless to say, an empty string argument is rather different from no argument, compare e.g. cat and cat '' for a simple example.

    The ${1+"$@"} is used to expand to exactly nothing if the first argument is not set (the ${1+ } part does this), but if the first argument is set (i.e. there are some arguments) it expands into "$@" which expands into each of the arguments, quoted against being broken at whitespace.

    If you didn't care about the whitespace, you see, you could just as easily use $* with no quotes (and a lot of Unix folks who would sooner dine with the devil than put a space in a filename still write shell scripts that way). But if you remember the early early early days of Perl, when Larry Wall was better known for a shell script generating tool called Configure, you can imagine why this ${1+"$@"} is still used.

    Nowadays, of course, ksh and bash and pretty much any modern shell that claims POSIX 'sh' compatibility does the right thing with just "$@" and you can use that in your scripts in most situations.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://825274]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2018-02-23 05:18 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (300 votes). Check out past polls.