Re: /dev/fd/62: No such file or directory

[Linda Walsh]

Pierre Gaston wrote:
> your test will also fail if there is one file named "*"  it' better to 
> just [[ -e ${entries[0]} ]]

Sigh...so you are saying that:

    [[ ${entries[0]} == "$1/*" ]] && return 0

would fail if someone has a file named '*'.

Hmmm...and whether the file exists or not, 'entries' will
still have 'arg1/*' in it so I can test it without worrying
about an 'unset' error.  It's not that I'm running with
-u set normally, but these scripts get called from
various contexts, so want to make sure they don't
suffer from things that I know are possible.

This script would normally only be called at login or
by some system-start scripts. Either way, the env
is fairly predictable at those points (e.g. - not likely
'nullglob').  But protecting against refs to "unset vars"
is necessary, as I've seen some scripts that start
with "bash -u" at the top.  Though, in my particular
use case, if there was only a file named '*' in
the directory -- having it return 0 would be ok, as
this is used to decide whether or not to add a directory
to your PATH when bash is starting -- so even if '*'
was an executable, and it's the only thing in a 'dir',
I don't think that "not adding" that dir to the PATH
would be a problem, and it might be a positive (who
names files '*' and expects to invoke them via
the PATH?).

I have never used the [[ xxx == ?xx*xx ]] construct
to do matching.  I would have defaulted to =~ and
used an RE... but I can see there might be times
the other might be useful...but I see it as bit
arcane and would likely still tend to use an RE,
instead, in my own code.

So thanks Chris for the fast reminder lesson (I vague
remember having known that in the past, but it wasn't
something I actively remembered)..