[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bash and variable holding directories with spaces



On Tue, Dec 06, 2005 at 04:07:02PM -0500, Andrew Cady wrote:
> On Sun, Dec 04, 2005 at 12:11:22AM +0100, Almut Behrens wrote:
> > On Sat, Dec 03, 2005 at 05:58:28PM -0500, H.S. wrote:
> >
> > > $ DIRS="'file\ 1 file\ 2'"; ls -ln "$DIRS"
> > > ls: 'file\ 1 file\ 2': No such file or directory
> > 
> > in this case you probably want
> > 
> > $ DIRS='file\ 1 file\ 2';  eval ls -ln $DIRS
> 
> I'm not sure quite what the requirements are here, but although this
> works it would probably be more natural either to use perl or to use an
> array.  For a shell script, this would be more appropriate, being both
> portable and straightforward:
> 
> set "file 1" "file 2"
> ls -ln "$@"
> 
> Of course, this clobbers the "$@" array.  Better shell script style is
> to arrange your code to allow something like:
> 
> ls_ln() { ls -ln "$@"; }
> ls_ln "file 1" "file 2"
> 
> You could use a non-portable bash array:
> 
> DIRS=("file 1" "file 2")
> ls -ln "${DIRS[@]}"
> 
> Seriously though, shell scripting sucks.  Perl!  It's on every debian
> system with debconf.

I absolutely agree with you here.  I love perl myself.  OTOH, I'm
trying to resist the urge to go telling people to use it as the "golden
hammer" for each and every scripting problem they come up with.
I'm kinda feeling that might be perceived as inappropriate -- unless
they explicitly seem to be wanting advice on such matters, of course.
But maybe that's just me...  Anyway.

All I was trying to point out is that it's good to remember there's
"eval" when you find yourself wondering why some scripted shell command
containing interpolated variables doesn't behave as expected, i.e. as
if you had typed the same (expanded) string of letters on the
interactive commandline.  That's all.

Of course, as always, TIMTOWTDI, YMMV, and all that :)

Almut



Reply to: