jasonh@syma.sussex.ac.uk (Jason Handby) (09/27/89)
I'm using mush 6.5.6 on a Sequent Symmetry running Dynix 3.0.15 .
The program development environment which we use at Sussex is called
Poplog, and the principle language involved is pop11. This is
accessed using the UNIX command "pop11". Unfortunately, mush won't
deal with UNIX commands that contain numbers in their name (or
anywhere in the path: if you're unlucky enough to have
/user2/cogs/jasonh as your home directory, you can't run commands in
your directory tree using their full pathnames). So I can't run
pop11 from mush, as it thinks I'm trying to run a UNIX command
called "pop". This would seem to be an error in the way mush
itemises text on the command line --
a) has anyone else had this problem, or is it just me?
b) If it is a bug, how about a fix? My C is not really up
to it... :-)
Many thanks,
Jason
---
Jason Handby |
School of Cognitive and Computing Science| JANET: jasonh@uk.ac.sussex.syma
University of Sussex |
England |schaefer@ogccse.ogc.edu (Barton E. Schaefer) (09/29/89)
In article <1398@syma.sussex.ac.uk> jasonh@syma.sussex.ac.uk (Jason Handby) writes: } } I'm using mush 6.5.6 on a Sequent Symmetry running Dynix 3.0.15 . } The program development environment which we use at Sussex is called } Poplog, and the principle language involved is pop11. This is } accessed using the UNIX command "pop11". Unfortunately, mush won't } deal with UNIX commands that contain numbers in their name (or } anywhere in the path: [....] ). This is a documented backwards-to-ucbMail-feature. In Mail, it is not necessary to separate message numbers/metachars from command names; so you can use "d11" to delete message 11. Mush wants to be a little more structured in its parsing, but also wants to maintain Mail compatibility. So it inserts a space to the left of any digit-string or .*^$ it finds. Breaking at numbers in the middle of a path like /user2/... is obviously beyond the intent of this parsing. Shutting it off following a `/' is a fairly trivial change, which I will make a note to get into the next release. That doesn't help with "pop11". HOWEVER, mush does handle quoted strings correctly, that is, it does not break up words in quotes. To run pop11, you need only use mush> 'pop11' However part 2, mush does NOT break up the words after history (!* etc.) expansion is done, so you can make a general fix: cmd pop 'pop\!*' which pastes the 11 back against the word "pop": pop11 args --> (pop) (11) (args) --> (pop11) (args) ^--- !* --^ ^-- !* --^ By "general fix," I mean it will also work for your home directory: cmd /user '/user\!*' Hence it doesn't matter what the "tail" of the path is. The /user will only be broken out when followed by a digit, as in /user2/cogs; the cmd expansion will not happen to /user/anything/else. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
msir@uhura.cc.rochester.edu (Mark Sirota) (09/29/89)
In article <4889@ogccse.ogc.edu> schaefer@ogccse.UUCP (Barton E. Schaefer) writes: >In article <1398@syma.sussex.ac.uk> jasonh@syma.sussex.ac.uk (Jason Handby) writes: >> Unfortunately, mush won't deal with UNIX commands that contain numbers in >> their name (or anywhere in the path: [....] ). > > This is a documented backwards-to-ucbMail-feature. In Mail, it is not > necessary to separate message numbers/metachars from command names; so > you can use "d11" to delete message 11. Mush wants to be a little more > structured in its parsing, but also wants to maintain Mail compatibility. > > Breaking at numbers in the middle of a path like /user2/... is obviously > beyond the intent of this parsing. Shutting it off following a `/' is > a fairly trivial change, which I will make a note to get into the next > release. All right, let's get philosophical here. Some of us, perhaps many of us, no longer give a damn about UCB Mail, and would happily get rid of these braindead behaviors for backwards compatibility. I want a mailer that works right, not one that works similarly to another braindead mailer. I think the shutting-it-off-after-a-slash is not enough. It's a band-aid; it's curing the symptom, not the problem. The problem is that no parser can expect to do a reasonable job if there isn't any known delimiter between the command and its arguments. Give us a variable we can set (or unset, or whatever) to make it act right. You've already given us the "newline" variable along these lines... Keep up the good work. -- Mark Sirota - University of Rochester, Rochester, NY Internet: msir@cc.rochester.edu Bitnet: msir@uordbv.bitnet UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/29/89)
In article <3166@ur-cc.UUCP> Mark Sirota writes: >All right, let's get philosophical here. Some of us, perhaps many of us, no >longer give a damn about UCB Mail, and would happily get rid of these >braindead behaviors for backwards compatibility. I want a mailer that works >right, not one that works similarly to another braindead mailer. I can't rightly say whether I've >ever< used UCB Mail, but I would strenuously object if "d11" stopped working. Kludge solution: after all parsing, if it turns out NOT to be an internal command (build-in or cmd), go back and reparse it with break-at-digit turned off. Or just keep a flag whether a break-at-digit was done during parse; when it's determined to be an external command, shove together the first two words if that flag is set. Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (09/30/89)
In article <42.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes: } In article <3166@ur-cc.UUCP> Mark Sirota writes: } >All right, let's get philosophical here. Some of us, perhaps many of us, no } >longer give a damn about UCB Mail, and would happily get rid of these } >braindead behaviors for backwards compatibility. I want a mailer that works } >right, not one that works similarly to another braindead mailer. } } Kludge solution: after all parsing, if it turns out NOT to be an internal } command (build-in or cmd), go back and reparse it with break-at-digit turned } off. Or just keep a flag whether a break-at-digit was done during parse; } when it's determined to be an external command, shove together the first two } words if that flag is set. The problem with that is coming up with a definition of "after parsing". Presently, builtin lookup is not done until after cmd (alias) lookup and expansion; word splitting is of necessity done before cmd lookup. Even supposing we are willing to sacrifice efficiency to add an extra builtin lookup somewhere, there is still the possibility that cmds/builtins are a prefix of some external command, so the wrong decision would be made. What is needed is a way to look up external commands, but that is even more inefficient and prone to wrong decisions than an extra internal lookup. So suppose we wait until after cmd expansion,and THEN it turns out not to be a builtin. Is it safe to "shove together the first two words"? Well, maybe, but only if cmd expansion didn't change anything ... and with the possibility of a cmd expanding recursively, and/or expanding to an external command, that's a difficult question. It isn't necessarily impossible to keep track of all the variations, but it certainly doesn't seem like the best way to handle things. So it seems the choice is the one Mark originally implied: either do word splitting at message numbers/metachars, or don't. -- Bart Schaefer "Oooh, ick!" -- Penfold CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/30/89)
In article <4921@ogccse.ogc.edu> Barton E. Schaefer writes: >So it seems the choice is the one Mark originally implied: either do >word splitting at message numbers/metachars, or don't. Then please make it a user-settable option... Mark can set it and run his xyz123 program, I can leave it alone and do my d11. :-) >Bela<