🚀 go-pugleaf

In article <1989Nov22.064230.13339@semi.harris-atd.com>
    del@semi.harris-atd.com (Don Lewis) writes:
} In article <128221@sun.Eng.Sun.COM> argv@sun.UUCP (Dan Heller) writes:
[ >I (Bart) wrote: ]
} >> The function keys are going away altogether as I understand it.
} >As a replacement (someday), there is going to be a "command"
} >window similar to dbxtool, maybe.  That is, you will be able to enter
} >mush commands directly from a special window or prompt.
} 
} But in the mean time, the function keys are the only way to do useful
} operations that are not possible given the buttons and menus.

WARNING!  AWFUL CRUFTY UNDOCUMENTED USE-AT-YOUR-OWN-RISK TRICK FOLLOWS!

You can actually execute *any* line-mode command from tool mode, but be
warned that if the command produces output you might be in deep doodie.
Also, the number of commands for which this trick works has shrunk with
every new toolmode patch since 6.5.6; I have no idea which ones break any
given version, but I believe "echo" breaks all of them ....

Here's the trick:

Select the <Folder> button, which changes the Filename: prompt to Folder:.

Backspace over any file name that may already be on the prompt line.

Type a semicolon followed by any line mode command, e.g:

    Folder: ;mail -f

Type a carriage return and hold your breath.  Either the command will work
exactly as it should, or mush will dump core; there is no in-between.

} The following is a patch to what appears to be an real tool mode bug.  I
} think this one actually bit me the other day.  I hit the done button
} just about the time new mail was coming in and mushtool hung trying to
} read from fd 0.  I don't really know if there should be some explicit
} tool mode code here, but the original is clearly wrong.

[ Diff deleted ]

This piece of code has changed a bit; the indentation was still wrong
(I just corrected it), but the tool mode code needed had been added.

} I noticed that if you hit the update button and your folder is already
} up to date, mushtool doesn't ask if you want to update the folder, but
} it does go off and think for quit a while.  It's not obvious what it is
} doing.

I believe it's re-reading the folder.  Update always causes a complete
re-load of the folder, even if nothing was written back.

} I noticed in msgs.c that the permission checking on the folders is done
} by checking the owner permission bits returned by stat().  This is not
} correct if the folder is owned by another user.  Shouldn't the access()
} system call be used instead?

Sigh.  It's a no-win situation.  If you use access(), the result is wrong
when you are running setuid (with different real and effective uids).  If
you use stat(), you don't know which set of permission bits to check
without doing a *lot* of extra work.  Fortunately, the primary use of the
function that calls stat() is to determine whether a file exists, and in
those cases where the bits actually are important, the code is redundant
and catches the permissions mismatch at a later stage.
-- 
Bart Schaefer          "Sometimes I think the surest sign that intelligent life
                        exists elsewhere in the universe is that none of it has
schaefer@cse.ogi.edu        tried to contact us."                     -- Calvin
(used to be cse.ogc.edu)