Re: [Nmh-workers] whatnow(1)'s cd Doesn't Affect it's mime.

[Jon Steinhart]

Ralph Corderoy writes:
> Hi Jon,
> 
> > David wrote:
> > > > It's very unintuitive, well, wrong, that a `cd' command at a
> > > > command's prompt doesn't change the current working directory as
> > > > far as all other commands are concerned.  That's not how other
> > > > Unix commands that provide cd work.  If it can't be fixed then
> > > > whatnow(1) could do with pointing it out.
> > >
> > > Well, yeah.
> >
> > Well, since I'm responsible for this, I don't agree with you.  Yes, it
> > might be unintuitive if you're not familiar with UNIX, but it is how
> > it works.  If you type
> > 
> >     sh
> >     cd foo
> >     exit
> > 
> > you will not be in foo.  Whatnow is a subshell.
> 
> I have some familiarity with Unix.  ;-)
> 
> My complaint, and whatnow(1)'s behaviour, is, in normal sh terms, more
> akin to
> 
>      1  $ pwd
>      2  /
>      3  $ mkdir foo
>      4  $ date >foo/bar
>      5  $ cd foo
>      6  $ pwd
>      7  /foo
>      8  $ ls
>      9  bar
>     10  $ cat bar
>     11  cat: bar: No such file or directory
>     12  $ cat foo/bar
>     13  2017-01-18 12:51:06 +0000 Wed
> 
> It's like a sh(1) that implements its built-in `cd' without calling
> chdir(2), instead tracking cwd as a string to supplement other commands,
> but only some of them.  Thus, 6 and 8 "lie" that we've chdir'd, yet 10's
> cat, not one of the annointed commands, can't find bar and must instead
> must give a path as if the cd didn't happen.  cat here is `mime' at the
> whatnow prompt.
> 
> When implementing this, was there a reason whatnow doesn't implement
> `cd' with chdir, as normal Unix commands that offer cd do, and instead
> "fake" it for `pwd', `ls', and `attach', but not `mime', etc?

Well, the most honest answer that I can give is that I did this so long ago
that I just don't remember.  I would guess that I realized that it wasn't
good to make users compose messages from the directory that contained the
potential attachments or to make them use full path names, so this limited
functionality made the UI more palatable.

I do think that your example above is sort of bogus; whatnow does not
provide full shell functionality so you can't do things like that anyway.

My personal opinion is that whatnow is a convenient but paradigm-breaking
part of nmh being the only "interactive" command, and that anybody who
really needs full shell behavior is better off making and using separate
shell commands for compose, attach, and send.

Also, I do not recall any other "UNIX commands that provide cd" at the time
I wrote this code except for shells which do not change their parent directory
and things like "more".  If I do "more foo" and "!cd bar" and then quit "more"
I'm not in "bar" so it's the same behavior as currently in whatnow.

Ah, some minor piece of memory was jogged here.  My goal was to make sending
attachments usable by non-geeks, mainly my wife.  I feel like I succeeded as
the code is still in use basically unchanged except for some cosmetic things.
I did think about the shell-like behavior in whatnow, and decided to meet my
goal instead of chasing corner cases.  I felt that the corner-case chasers
could just stick with hand-crafting composition files.  I realized that once
I started with shell-like behavior I would likely get complaints about "why
doesn't pushd/popd work" and other shell features.

So the bottom line is that it works for the intended purpose.  If the purpose
has expanded or changed then change the code.  But I think that if you changed
this then the next corner case would arise, and eventually you'd end up at the
"don't use whatnow" position.

Hope that that answers your question although obviously in a not very satisfying
way.

Jon