From aberry@tiuk.ti.com

If I use glob to match a series of wildcards it appears to work as I want
(and would expect) in one case but fail in another. This seems to be
inconsistent behaviour.

example :

@​files = glob "/user/a/*.txt /home/a/*.txt";

case 1​: /user/a/fred.txt exists, /home/a exists but there are no *.txt matches.

  This works and returns ("/user/a/fred.txt") in @​fred.

case 2​: /user/a/fred.txt exists, /home/a does not exist

  @​files returns as an empty array.

Surely glob should still return the /user/a/*.txt match ?

So in summary, the whole glob "fails" if one of the directories in any of the
expressions does not exist. Yet for no matches of a file in a directory it
"works".

FYI I also got the same behaviour with 5.004_04

Site configuration information for perl 5.003​:

Configured by a904209 at Tue Nov 26 14​:18​:36 GMT 1996.

Summary of my perl5 (5.0 patchlevel 3 subversion 0) configuration​:
  Platform​:
  osname=solaris, osver=2.5, archname=sun4-solaris
  uname='sunos pluto 5.5 generic sun4m sparc sunw,sparcstation-10 '
  hint=recommended, useposix=true, d_sigaction=define
  Compiler​:
  cc='gcc', optimize='-O2 -g', gccversion=2.7.2
  cppflags='-DDEBUGGING -I/usr/local/include'
  ccflags ='-DDEBUGGING -I/usr/local/include'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  voidflags=15, castflags=0, d_casti32=define, d_castneg=define
  intsize=4, alignbytes=8, usemymalloc=y, randbits=15
  Linker and Libraries​:
  ld='gcc', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt
  libc=, so=so
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=, ccdlflags=' '
  cccdlflags='-fpic', lddlflags='-G -L/usr/local/lib'

From [Unknown Contact. See original ticket]

This is a bug report for perl from aberry@​ti.com,
generated with the help of perlbug 1.13 running under perl 5.003.

If I use glob to match a series of wildcards it appears to work as I want
(and would expect) in one case but fail in another. This seems to be
inconsistent behaviour.

  % mkdir user home user/a
  % touch user/a/fred.text

  % perl -le 'for (glob("{home,user}/a/*.text")) { print }'
  user/a/fred.text

  % ls -R
  .​:
  home/ user/

  home​:

  user​:
  a/

  user/a​:
  fred.text

That's the same in 5.005_61, and in 5.005_62 with -DPERL_INTERNAL_GLOB.

--tom

From [Unknown Contact. See original ticket]

Tom,

% perl \-le 'for \(glob\("\{home\,user\}/a/\*\.text"\)\) \{ print \}'
user/a/fred\.text

Thanks for the solution to my example. Perhaps I should have illustrated
the problem with a more realistic example of what I was trying to achieve
through globbing :

glob "/adir/xdir/*.lic /adir/ydir/something.dat /home/bdir/cdir/*/etwas.dat /home/kdir/ldir/mdir/afile.ext"

i.e. some set of wildcards not easily represented as one wildcard.
So my question is - is it reasonable to expect glob to "fail" when multiple
wildcards are used in the manner I described?

BTW, I changed my code to build up the list of matches from multiple calls to
glob since I couldn't come up with a single regexp that matched all the files
that I was looking for.

Regards, Andy

From [Unknown Contact. See original ticket]

aberry@​ti.com writes​:

glob "/adir/xdir/*.lic /adir/ydir/something.dat /home/bdir/cdir/*/etwas.dat /home/kdir/ldir/mdir/afile.ext"

This *should* match files with names starting with "/adir/" etc. and
ending with etc-"afile.ext". And these files should contain 3 spaces
in their names in appropriate places.

This may be not how the current (broken) implemenation is/was working,
but this is the only sane solution I see.

One can use

  @​files = map glob, qw(/adir/xdir/*.lic
  /adir/ydir/something.dat
  /home/bdir/cdir/*/etwas.dat
  /home/kdir/ldir/mdir/afile.ext);

if the older semantic is needed.

Ilya

From [Unknown Contact. See original ticket]

On Thu, 21 Oct 1999 16​:41​:59 -0400 (EDT)
  Ilya Zakharevich <ilya@​math.ohio-state.edu> wrote
  using ELM [version 2.5 PL2]
  in <199910212041.QAA00869@​monk.mps.ohio-state.edu>​:

aberry@​ti.com writes​:

glob "/adir/xdir/*.lic /adir/ydir/something.dat /home/bdir/cdir/*/etwa<SNIP>

This *should* match files with names starting with "/adir/" etc. and
ending with etc-"afile.ext". And these files should contain 3 spaces
in their names in appropriate places.

This may be not how the current (broken) implemenation is/was working,

s/broken/unfortunate/

but this is the only sane solution I see.

One can use

@​files = map glob, qw(/adir/xdir/*.lic
/adir/ydir/something.dat
/home/bdir/cdir/*/etwas.dat
/home/kdir/ldir/mdir/afile.ext);

if the older semantic is needed.

Well, I think you're probably right (No, you may not use
those words against me.)

But I wonder a bit....

% touch "this file" this file

% perl5.004 -e 'for(glob("*this* *file*")) { printf "%d​: %s\n", $i++, $_ }'
0​: this
1​: this file
2​: file
3​: this file

% perl5.005_62 -e 'for(glob("*this* *file*")) { printf "%d​: %s\n", $i++, $_ }'
0​: this
1​: this file
2​: file
3​: this file

And yes, that's with -DPERL_INTERNAL_GLOB. I'm not getting
different answers. Now I'm unclear about what the alleged "problem"
even was to start with.

What happened to glob("*this*", "*file*")?

% perl -e 'for(glob("*this*", "*file*")) { printf "%d​: %s\n", $i++, $_ }'
0​: this
1​: this file

Hm... that looks wrong. I think it ignored the second argument.
And yes, I did test with -w, too.

You know, Unix has had ability to put spaces in filenames for what,
going on three decades now? Yet we've virtually always had the good
taste not to such a nicky thing. Give those CP/M wascals something more
than 8·3 and the first thing they do is put it all over the place.
Alas. You'd think they could fix their shell first.

-tom

From [Unknown Contact. See original ticket]

On Thu, Oct 21, 1999 at 03​:14​:56PM -0600, Tom Christiansen wrote​:

You know, Unix has had ability to put spaces in filenames for what,
going on three decades now? Yet we've virtually always had the good
taste not to such a nicky thing.

This may be related to the fact that most of what these *nix machines
were used for was *nix administration. Kind of eternal
bootstrapping. ;-)

Give those CP/M wascals something more
than 8·3 and the first thing they do is put it all over the place.
Alas. You'd think they could fix their shell first.

Usability of shells for non-administrative tasks is greatly
exaggerated. ;-)

I think a lot of people (even if we restrict our attention to those
who use computers *productively*) may not even suspect an existence of
shells and other programming languages on their computers.

IDE are very restrictive, but as far as they answer your needs, you do
not need no fricking shell.

Ilya