Re: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current folder becomes accessible

[Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>]

christos%zoulas.com@localhost (Christos Zoulas) wrote:
 | On Feb 18,  2:25pm, sdaoden%gmail.com@localhost 
(sdaoden%gmail.com@localhost) wrote:
 | -- Subject: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current \
 |folde
 | 
 || 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 \
 |  accessible.
 || You need to cd to a path which turns the relative folder path accessible \
 |  again to be able to continue.
 || This is just one facet of a basic architectural problem of Berkeley Mail, \
 |  i.e., concurrent deletion of the current folder etc. still bails, but for \
 |  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.

 | christos

--steffen