Re: /bin/sh tilde expansion

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 14-Jul-08, at 7:05 PM, James K. Lowden wrote:

> Greg A. Woods; Planix, Inc. wrote:
> > It seems tilde expansion is broken for /bin/sh (on NetBSD-4 at least)
> > when the command is "export".
>
> That's not exactly it, although I'm not sure what is.  Consider this
> Makefile:
>
> $ cat Makefile.tilde
> all:
>         ls > /tmp/.t
>         mv /tmp/.t /tmp/t
>         mv /tmp/t ~/
>         
> $ make -f Makefile.tilde
> ls > /tmp/.t
> mv /tmp/.t /tmp/t
> mv /tmp/t ~/
> mv: rename /tmp/t to ~/: Not a directory
> *** Error code 1

That's the result of an entirely different issue, and one with "make",  
not "sh".

The '~' is not expanded in those commands because "make" never  
executes /bin/sh to run them -- instead it directly executes /bin/mv.

Try this makefile:

        all:
                true && echo ~

Perhaps "make" should recognize '~' as a shell meta-character, but I'd  
say anyone writing makefiles with such constructs (i.e. instead of  
using $$HOME explicitly) is just asking for big trouble.

As for the original problem, well it's not just "export" -- it's any  
parameter for any normal command where the '~' is not the first  
character in the parameter, eg.:

        sh -c 'echo foo=~/bar'

If you look in the /bin/sh sources you'll find there's a hack for  
expanding '~' in variable assignments, either alone as separate  
statements, or prior to the command name, eg.:

        sh -c 'foo=~/bar sh -c "echo \$foo"'

Ksh seems to always expand the '~', and indeed the /bin/sh code does  
call the literally call its own handling of '~' in variable  
assignments a ``hack''.

HOWEVER, from my cursory reading of the Single UNIX Specification it  
would seem that /bin/sh is conforming as-is -- i.e. the tilde  
character is only to be recognized and expanded if it is an unquoted  
character at the beginning of a word (except in an assignment where  
multiple tilde-prefixes can be used with subsequent ones recognized  
after any unquoted colon character).

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>