[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current folder becomes accessible
The following reply was made to PR bin/47577; it has been noted by GNATS.
From: Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
Subject: Re: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current
folder becomes accessible
Date: Mon, 18 Feb 2013 19:19:07 +0100
christos%zoulas.com@localhost (Christos Zoulas) wrote:
| On Feb 18, 2:25pm, sdaoden%gmail.com@localhost
| -- Subject: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current =
|| If you open a folder with a relative path, use the cd command to change=
| the current working directory, then any action that needs to update the=
| opened folder (as opposed to the temporary MBOX; e.g., switching to a \
| different folder) will fail and claim that the opened folder is not \
|| You need to cd to a path which turns the relative folder path accessibl=
| again to be able to continue.
|| This is just one facet of a basic architectural problem of Berkeley Mai=
| i.e., concurrent deletion of the current folder etc. still bails, but f=
| this particular aspect the solution is easy.
| I think it is better to canonicalize the name when the name is set? No?
Sure; "fi" etc. then always show an absolute path, which is often
annoying imho, especially on 80 column terminals, though.
I as a user would then really like to see some
"/path1/[...]/folder" instead of "p1/p2/p3/p4/folder". I, e.g.,
often have problems with mksh(1) because that radically cuts job
paths at 40 (or so) characters, so that i sometimes have to check
ps(1) to know which job relates to what command.
So then i would possibly consider a basename(3)/realpath(3) tuple
(or, better, a path and an offset) from the begin on, the one for
display and the other for file operations.
Possibly overkill; I think even then i would delay the realpath(3)
until this very command is used, because (1) it is very expensive
(not that expensive with a getcwd() syscall, but still), and (2)
it is completely useless unless the cd command is used. I've just
encountered the problem that the Berkeley codebase stucks
completely unless the open folder comes into sight again, and that
was an at-a-glance solution for this particular problem, which
works automatically and without user interaction.
I haven't considered yet the basename(3)/realpath(3) solution;
hmmm; i think i look into that tomorrow, and come back with an
alternative patch if it's easy to implement -- i couldn't tell how
many places would need to be changed right now.
Main Index |
Thread Index |