Message-ID: [EMAIL PROTECTED]
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1 Build (9)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Just as a little sanity check: if you try `find /fs ...' and that
hangs, what happens when you do `cd /fs; find . ...'?
It hangs too (in
On Sat, 3 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote:
Just as a little sanity check: if you try `find /fs ...' and that
hangs, what happens when you do `cd /fs; find . ...'?
It hangs too (in fact that's what I've been doing all the time).
Right. This is starting to make sense, I think.
On 3 Jun 2000, Stefan Monnier
[EMAIL PROTECTED] wrote:
"Joe" == Joe Stoy [EMAIL PROTECTED] writes:
[...]
2. Is there another problem with filename completion too? If I do it
completely locally, for example with "tramp.", I can if I press TAB
often enough, get it t
a) ls -a 2/dev/null | f?grep ^%s
Of course, it's better to use `grep ^%s' than `fgrep %s' since it solves
both the leading dash and the substring issue, but then you have to
carefully requote your string.
Maybe something like:
(format "%s -a 2/dev/null | grep ^%s"
t this end of the hierarchy?
They're certainly the kind of directories where filename completion
would be nice...
j
Stefan Monnier writes:
"Kai" == Kai Großjohann [EMAIL PROTECTED] writes:
"Stefan Monnier" [EMAIL PROTECTED] writes:
There are many alternatives. For example using `ls -aF' instead
of `ls -a' would immediately give the directory info (ideal).
The `-F' argument for `ls' is too
Joe Stoy [EMAIL PROTECTED] writes:
I have to report, with regret, that the 'find' solution does not
solve my original problem: doing it on /fs still hangs. I don't know
why yet: for such directories . = .. ; but that shouldn't matter, I
suppose. Or there may be automounting problems.
with filename completion in a
long directory.
Hrm. I couldn't get this to break on my Linux machine with around 6K
OK -- I can reproduce the problem without involving tramp at all. It
turns out that for this particular directory (at least) the command
/bin/ls -d .*/ */ 2/dev/null | cat
Message-ID: [EMAIL PROTECTED]
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1 Build (9)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
/bin/ls -d .*/ */ 2/dev/null | cat
causes the /bin/ksh on the server (Solaris) to hang with no output.
Sigh. I think a few shells
"Kai" == Kai Großjohann [EMAIL PROTECTED] writes:
I'm not sure if it is possible to fix this easily. Hm. Maybe I could
`ls -l' the whole directory and then pick out the information that's
needed from that. Yes, that could work. But it might be
inefficient. I'll put it on the todo list
Kai Großjohann writes:
Kai "Stefan Monnier" [EMAIL PROTECTED] writes:
snip
Or else `find -type d -print ! -name . -prune'
Kai This sounds like a cool idea.
I think the -print should come last, or the . directory won't get removed.
--
Ted Stern
"Kai" == Kai Großjohann [EMAIL PROTECTED] writes:
"Stefan Monnier" [EMAIL PROTECTED] writes:
There are many alternatives. For example using `ls -aF' instead of `ls -a'
would immediately give the directory info (ideal).
The `-F' argument for `ls' is too non-standard.
I think there are
Joe Stoy [EMAIL PROTECTED] writes:
OK -- I can reproduce the problem without involving tramp at all. It
turns out that for this particular directory (at least) the command
/bin/ls -d .*/ */ 2/dev/null | cat
causes the /bin/ksh on the server (Solaris) to hang with no output.
I've
Kai Großjohann writes:
Joe Stoy [EMAIL PROTECTED] writes:
OK -- I can reproduce the problem without involving tramp at all.
It turns out that for this particular directory (at least) the
command
/bin/ls -d .*/ */ 2/dev/null | cat
causes the /bin/ksh on the server (Solaris)
"Stefan Monnier" [EMAIL PROTECTED] writes:
"Kai" == Kai Großjohann [EMAIL PROTECTED] writes:
The `-F' argument for `ls' is too non-standard.
I think there are Unices which don't have this at all,
I've never heard of such a system. Even my Unicos account accepted -F
although the most
Joe Stoy [EMAIL PROTECTED] writes:
Message-ID: [EMAIL PROTECTED]
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1 Build (9)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
(Are you aware that your mailer inserts the above as first body lines?)
Let's wait and see what the
"Stefan Monnier" [EMAIL PROTECTED] writes:
Or else `find -type d -print ! -name . -prune'
I have made a change to use this. However, the command does not
recognize unreadable directories -- I wonder why:
/
| $ find . -type d -print \! -name . -prune
| .
| ./.rpc_door
| ./mnt
|
"Stefan Monnier" [EMAIL PROTECTED] writes:
Or else `find -type d -print ! -name . -prune'
On Solaris:
/
| $ find . -prune -print
| .
| $ find . -print -prune
| .
\
This was run in a directory with subdirectories. Not very promising.
Too bad :-/
kai
--
I like BOTH kinds of music.
I don't see a hang under Solaris, but it can take a while.
Something like this should illustrate the problem under any UNIX.
time /bin/echo /*/*/*/* | wc
--
Pete Forman | Disclaimer: This posting is originated by
Western Geophysical | myself and does not represent the
"Stefan Monnier" [EMAIL PROTECTED] writes:
There are many alternatives. For example using `ls -aF' instead of `ls -a'
would immediately give the directory info (ideal).
The `-F' argument for `ls' is too non-standard. I think there are
Unices which don't have this at all, and on some of them
There is this todo item:
;; * Do not unconditionally use /bin/sh for local shell commands.
;; Instead, try to find out a local shell which groks tilde
;; expansion. (Mario DeWeerd)
I have now had a look at the two places where /bin/sh is executed
locally. Looks as if the tmp file names
21 matches
Mail list logo
