From: AndreasK on
On Jul 21, 5:04 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Jul 21, 1:04 pm, Georgios Petasis <peta...(a)iit.demokritos.gr>
> wrote:
>
> > Hi all,
>
> > Is "glob -nocomplain -directory $dir *" working for you? Because for me
> > its not!
> > It always returns the empty list, while glob -nocomplain $dir/* works!
>
> Possibly yet another weird remote filesystem trick (NFS or Samba).
> Please send an strace output (just the few lines near the end).

Is that for an NFS mounted directory ?

I had something similar recently for an OS X (*) box accessing an NFS
mounted directory. The basic command was

"glob -nocomplain -directory $dir */$subdir"

and in an interactive shell the first execution of the command failed,
and the second execution immediately after was OK. These were the only
commands executed in the tclsh. And after exiting the tclsh, then
starting a new one the same pattern was seen in the new shell.

The same behaviour for

"glob -nocomplain $dir/*/$subdir"

However the case given here, i.e.

"glob -nocomplain -directory $dir *"

was ok. I noted 'interactive' tclsh, because in a non-interactive
shell repetition of the command did not make it work.

And the issue was gone after rebooting the machine in question.

We concluded that something had gotten weird in an NFS demon or some
such. Because renaming the directory the * stood for to a slightly
older name caused the problem to go away as well (The directory had
been renamed shortly before the problem started).

(*) I believe you (Georgios) are currently working more with OS X,
instead of Windows ?

--
Andreas
From: Georgios Petasis on
Στις 22/7/2010 00:14, ο/η AndreasK έγραψε:
> On Jul 21, 5:04 am, Alexandre Ferrieux<alexandre.ferri...(a)gmail.com>
> wrote:
>> On Jul 21, 1:04 pm, Georgios Petasis<peta...(a)iit.demokritos.gr>
>> wrote:
>>
>>> Hi all,
>>
>>> Is "glob -nocomplain -directory $dir *" working for you? Because for me
>>> its not!
>>> It always returns the empty list, while glob -nocomplain $dir/* works!
>>
>> Possibly yet another weird remote filesystem trick (NFS or Samba).
>> Please send an strace output (just the few lines near the end).
>
> Is that for an NFS mounted directory ?
>
> I had something similar recently for an OS X (*) box accessing an NFS
> mounted directory. The basic command was
>
> "glob -nocomplain -directory $dir */$subdir"
>
> and in an interactive shell the first execution of the command failed,
> and the second execution immediately after was OK. These were the only
> commands executed in the tclsh. And after exiting the tclsh, then
> starting a new one the same pattern was seen in the new shell.
>
> The same behaviour for
>
> "glob -nocomplain $dir/*/$subdir"
>
> However the case given here, i.e.
>
> "glob -nocomplain -directory $dir *"
>
> was ok. I noted 'interactive' tclsh, because in a non-interactive
> shell repetition of the command did not make it work.
>
> And the issue was gone after rebooting the machine in question.
>
> We concluded that something had gotten weird in an NFS demon or some
> such. Because renaming the directory the * stood for to a slightly
> older name caused the problem to go away as well (The directory had
> been renamed shortly before the problem started).
>
> (*) I believe you (Georgios) are currently working more with OS X,
> instead of Windows ?
>
> --
> Andreas

I am working on many operating systems. Not so much on OS X.
I have not yet an idea what is wrong, but in many cases I have faced
problems if I use -nocomplain and -directory, under windows & linux.
Yesterday, once again under ubuntu 64 my version of tclperl was not
loading, and I had to change the code from:

proc tclperl_load_unix {dir bits} {
set os $::tcl_platform(os)
set lib [info sharedlibextension]
foreach dll [lsort -dictionary -decreasing [concat \
[glob -nocomplain -directory $dir/$os/$bits libtclperl-3.2-*$lib] \
[glob -nocomplain -directory $dir/$os libtclperl-3.2-*$lib] \
[glob -nocomplain -directory $dir libtclperl-3.2-*$lib]]] {
if {![catch {CDM_load $dll Tclperl} error]} {
return
}
}
error $error
};# tclperl_load_unix

(the error was of course "undefined variable error", which cannot happen)

to:

proc tclperl_load_unix {dir bits} {
set os $::tcl_platform(os)
set lib [info sharedlibextension]
set error "$dir/$os/$bits/libtclperl-3.2-*$lib"
foreach dll [lsort -dictionary -decreasing [concat \
[glob -nocomplain $dir/$os/$bits/libtclperl-3.2-*$lib] \
[glob -nocomplain $dir/$os/libtclperl-3.2-*$lib] \
[glob -nocomplain $dir/libtclperl-3.2-*$lib]]] {
if {![catch {CDM_load $dll Tclperl} error]} {
return
}
}
error $error
};# tclperl_load_unix

Which worked. I don't know why, but it did. dir has whatever Tcl put
when loaded the pkgIndex.tcl file.

I know that it does not make sense (I failed to reproduce it), but I
have observed it many times. Something is there, but I don't know what :-)

Best regards,

George
From: Alexandre Ferrieux on
On Jul 22, 1:18 pm, Georgios Petasis <peta...(a)iit.demokritos.gr>
wrote:
> Στις 22/7/2010 00:14, ο/η AndreasK έγραψε:
>
>
>
>
>
> > On Jul 21, 5:04 am, Alexandre Ferrieux<alexandre.ferri...(a)gmail.com>
> > wrote:
> >> On Jul 21, 1:04 pm, Georgios Petasis<peta...(a)iit.demokritos.gr>
> >> wrote:
>
> >>> Hi all,
>
> >>> Is "glob -nocomplain -directory $dir *" working for you? Because for me
> >>> its not!
> >>> It always returns the empty list, while glob -nocomplain $dir/* works!
>
> >> Possibly yet another weird remote filesystem trick (NFS or Samba).
> >> Please send an strace output (just the few lines near the end).
>
> > Is that for an NFS mounted directory ?
>
> > I had something similar recently for an OS X (*) box accessing an NFS
> > mounted directory. The basic command was
>
> >      "glob -nocomplain -directory $dir */$subdir"
>
> > and in an interactive shell the first execution of the command failed,
> > and the second execution immediately after was OK. These were the only
> > commands executed in the tclsh. And after exiting the tclsh, then
> > starting a new one the same pattern was seen in the new shell.
>
> > The same behaviour for
>
> >      "glob -nocomplain $dir/*/$subdir"
>
> > However the case given here, i.e.
>
> >      "glob -nocomplain -directory $dir *"
>
> > was ok. I noted 'interactive' tclsh, because in a non-interactive
> > shell repetition of the command did not make it work.
>
> > And the issue was gone after rebooting the machine in question.
>
> > We concluded that something had gotten weird in an NFS demon or some
> > such. Because renaming the directory the * stood for to a slightly
> > older name caused the problem to go away as well (The directory had
> > been renamed shortly before the problem started).
>
> > (*) I believe you (Georgios) are currently working more with OS X,
> > instead of Windows ?
>
> > --
> > Andreas
>
> I am working on many operating systems. Not so much on OS X.
> I have not yet an idea what is wrong, but in many cases I have faced
> problems if I use -nocomplain and -directory, under windows & linux.
> Yesterday, once again under ubuntu 64 my version of tclperl was not
> loading, and I had to change the code from:
>
> proc tclperl_load_unix {dir bits} {
>    set os $::tcl_platform(os)
>    set lib [info sharedlibextension]
>    foreach dll [lsort -dictionary -decreasing [concat \
>      [glob -nocomplain -directory $dir/$os/$bits libtclperl-3.2-*$lib] \
>      [glob -nocomplain -directory $dir/$os libtclperl-3.2-*$lib] \
>      [glob -nocomplain -directory $dir libtclperl-3.2-*$lib]]]  {
>      if {![catch {CDM_load $dll Tclperl} error]} {
>        return
>      }
>    }
>    error $error
>
> };# tclperl_load_unix
>
> (the error was of course "undefined variable error", which cannot happen)
>
> to:
>
> proc tclperl_load_unix {dir bits} {
>    set os $::tcl_platform(os)
>    set lib [info sharedlibextension]
>    set error "$dir/$os/$bits/libtclperl-3.2-*$lib"
>    foreach dll [lsort -dictionary -decreasing [concat \
>      [glob -nocomplain $dir/$os/$bits/libtclperl-3.2-*$lib] \
>      [glob -nocomplain $dir/$os/libtclperl-3.2-*$lib] \
>      [glob -nocomplain $dir/libtclperl-3.2-*$lib]]]  {
>      if {![catch {CDM_load $dll Tclperl} error]} {
>        return
>      }
>    }
>    error $error
>
> };# tclperl_load_unix
>
> Which worked. I don't know why, but it did. dir has whatever Tcl put
> when loaded the pkgIndex.tcl file.
>
> I know that it does not make sense (I failed to reproduce it), but I
> have observed it many times. Something is there, but I don't know what :-)
>
> Best regards,
>
> George

Is it a local filesystem ? What kind ?

-Alex