Home > Archive > Tcl > February 2005 > odd glob behavior
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Matthias Kraft 2005-02-18, 4:00 pm |
| Hi *,
every now and then a certain [glob] behavior strikes me as odd:
Using bash on my Linux box:
matze@wedge:~> ls -l / | grep "[rb]oot$"
drwxr-xr-x 4 root root 1024 2004-12-22 13:19 boot
drwx------ 17 root root 832 2005-01-24 08:33 root
Now lets say I want to work on the files of both directories, at
least as far as my permissions allow. Using the shell again I get
makr@pcmakr1:~> echo /[rb]oot/*
/boot/boot /boot/boot.0800 [...]
/boot/vmlinuz.shipped /boot/vmlinuz.version.h
which is fine, as I do not have permissions to look into /root. Now
using Tcl, I'd thought [glob] is the command of choice, but see what
I get:
makr@pcmakr1:~> tclsh
% glob -nocomplain -- {/[rb]oot/*}
%
-> nothing?! Is it a bug?
Because of this behavior I have to maintain a function which looks up
the directories first and then builds a list of files where I have
access to.
kind regards
--
Matthias Kraft
Software AG, Germany
(They that can give up essential liberty to obtain a little temporary)
(safety deserve neither liberty nor safety. -- Benjamin Franklin)
| |
| Arjen Markus 2005-02-18, 4:00 pm |
| Matthias Kraft wrote:
>
> -> nothing?! Is it a bug?
>
> Because of this behavior I have to maintain a function which looks up
> the directories first and then builds a list of files where I have
> access to.
>
Hm, it must be related to the permissions on /root:
I created two subdirectories, root and boot, under an arbitrary
directory, with the boot subdirectory holding a single file "a"
(I am not very imaginative with this kind of tests ;)).
The result:
% glob -nocomplain -- {./[rb]oot/*}
../boot/a
Regards,
Arjen
| |
| Bruce Hartweg 2005-02-18, 4:00 pm |
|
Arjen Markus wrote:
> Matthias Kraft wrote:
>
>
>
>
> Hm, it must be related to the permissions on /root:
>
> I created two subdirectories, root and boot, under an arbitrary
> directory, with the boot subdirectory holding a single file "a"
> (I am not very imaginative with this kind of tests ;)).
>
> The result:
>
> % glob -nocomplain -- {./[rb]oot/*}
> ./boot/a
>
exactly, to see more remove the -nocomplain if glob
can;t read a directory (like if it doesn't have permissions)
then it throws an error and doesn't return any results, with
the nocomplain option it suppresses the error but it has still
given up on results. I'm not sure if it should be a bug report
or a feature request, but it would be nice if nocomplin would
work a little lower & catch/ignore the error and then continue
with other parts of the glob expr.
Bruce
| |
| Matthias Kraft 2005-02-21, 8:58 am |
| Bruce Hartweg wrote:
> exactly, to see more remove the -nocomplain if glob
> can;t read a directory (like if it doesn't have permissions)
> then it throws an error and doesn't return any results, with
> the nocomplain option it suppresses the error but it has still
> given up on results. I'm not sure if it should be a bug report
> or a feature request, but it would be nice if nocomplin would
> work a little lower & catch/ignore the error and then continue
> with other parts of the glob expr.
That's exactly what I expect it to do. OTOH the documentation is a
little bit problematic, because it doesn't even cover the case:
----
-nocomplain
Allows an empty list to be returned without error; without this
switch an error is returned if the result list would be empty.
----
.... well, the list shouldn't be empty. That brings me to believe
the -nocomplain flag shouldn't even be needed, as [glob] shouldn't
throw an error anyway:
----
This command performs file name ``globbing'' in a fashion similar to
the csh shell. It returns a list of the files whose names match any
of the pattern arguments.
----
.... and ...
----
The glob command differs from csh globbing in two ways. First, it
does not sort its result list (use the lsort command if you want the
list sorted). Second, glob only returns the names of files that
actually exist; in csh no check for existence is made unless a
pattern contains a ?, *, or [] construct.
----
So I am now confident, it is a bug in [glob] indeed. If nobody tells
me otherwise I will open report at sf.net...
kind regards
--
Matthias Kraft
Software AG, Germany
(They that can give up essential liberty to obtain a little temporary)
(safety deserve neither liberty nor safety. -- Benjamin Franklin)
| |
| Matthias Kraft 2005-02-22, 4:02 pm |
| Matthias Kraft wrote:
> So I am now confident, it is a bug in [glob] indeed. If nobody tells
> me otherwise I will open report at sf.net...
Logged as Tcl bug:
[ 1146047 ] Unexpected [glob] result, when match is partly inaccessable
kind regards
--
Matthias Kraft
Software AG, Germany
(They that can give up essential liberty to obtain a little temporary)
(safety deserve neither liberty nor safety. -- Benjamin Franklin)
|
|
|
|
|