sorrow@oak.circa.ufl.edu (06/22/91)
Well, in response to my post about trying to make my DOS environment look like UNIX yet retain compatiblity, I found about this wonderful thing called the MS-DOS GNUish project which has about 98.5% of the utilities I need already done. However... These utilites are HARD CORE implementations of the UNIX stuff, and what I really wanted was an implementation that is UNIX-like but handles DOS special cases. For example, LS by GNU shows owner (invalid concept), group access, and does NOT show time. Mine shows attributes, time, and doesn't bother with owner. Ho hum. Second, there is no utility with the GNU stuff to do command line completion and command line history and editing. I downloaded from wuarchive a little utility called HISTORY.COM with it's source and it looks real good. However, it is dated 1988 and was written by Michael Rubinstein and Russell Nelson. What I would like to know is if I can rewrite the code (it is UGLY) then reupload it as freeware. It was written in Aztec C but ported to BC++ just fine (in C mode). TASM compiled the one .ASM file perfectly. Also, I changed it so that it was more UNIXy (BSD...I use the tab key for completion). Finally, I need more help (yes, MORE help) on how to make my prompt use forward slashes. Someone told me to intercept the DOS INT that returns the correct working directory....is this safe? Anything I should know about that? Any replies appreciated, Brian /* Brian Hook -- MS-DOS Programmer for Contract ----------------------------------------------------------------- "Seamus, that's my dog...I saw her today at the reception...sorry, sixTEEN inches....better save the women and children first...but this one goes to 11! ..anymore of that plutonium nyborg?....there can be only ONE!....like a finger pointing to the moon....ease the seat back...one day closer to death */
nelson@sun.soe.clarkson.edu (Russ Nelson) (06/23/91)
In article <0094A761.C2F6D640@MAPLE.CIRCA.UFL.EDU> sorrow@oak.circa.ufl.edu writes:
Second, there is no utility with the GNU stuff to do command line
completion and command line history and editing. I downloaded from
wuarchive a little utility called HISTORY.COM with it's source and
it looks real good. However, it is dated 1988 and was written by
Michael Rubinstein and Russell Nelson. What I would like to know
is if I can rewrite the code (it is UGLY) then reupload it as
freeware.
Yes, it's UGLY, but it doesn't take up too much memory either.
It was written in Aztec C but ported to BC++ just fine (in C mode).
TASM compiled the one .ASM file perfectly.
No, Michael wrote it in Aztec C and I ported it to Turbo C.
Also, I changed it so that it was more UNIXy (BSD...I use the tab
key for completion).
Yes, I'd change that also (now).
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
I am leaving the employ of Clarkson as of June 30. Hopefully this email
address will remain. If it doesn't, use nelson@gnu.ai.mit.edu.pshuang@athena.mit.edu (Ping-Shun Huang) (06/24/91)
In article <0094A761.C2F6D640@MAPLE.CIRCA.UFL.EDU> sorrow@oak.circa.ufl.edu writes: > Finally, I need more help (yes, MORE help) on how to make my prompt use > forward slashes. Someone told me to intercept the DOS INT that returns > the correct working directory....is this safe? This would probably be a bad thing to do. Not dangerous per se, but it would almost certainly break a lot of programs. If you were to intercept the DOS service which returns the current working directory (I don't know which one it is off the top of my head) and return a modified string instead, your program may work the way you want. COMMAND.COM interpretation of the metacharacter "$P" in the PATH variable may work as you would want it. CD's default response when you don't give it a any parameters would be consistent. However, any code which calls the DOS service not just to print to the screen, but to actually make use of the path returned thereafter (e.g. programs which switch the default directory while in operation, but are polite enough to save the directory you were in when you started it up) will break, because when they pass the path with forward slashes back to DOS, DOS will puke. If you feel strongly about this, you could also intercept *ALL* DOS services which accept path names and translate forward slashes into backslashes, and *ALL* DOS services which return any kind of path and perform the vice versa translation. Then you would "always" be able to use forward slahes... exceptions being when you use low-level applications which do not go through DOS. Also, many programs may try to interpret any filenames you provide on the command line as a switch. -- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu]
ralf+@cs.cmu.edu (Ralf Brown) (06/24/91)
In article <PSHUANG.91Jun23155134@beeblebrox.mit.edu> pshuang@athena.mit.edu (Ping-Shun Huang) writes: }intercept the DOS service which returns the current working directory (I }don't know which one it is off the top of my head) and return a modified }string [with forward slashes] instead, [...] }the path returned thereafter (e.g. programs which switch the default }directory while in operation, but are polite enough to save the }directory you were in when you started it up) will break, because when }they pass the path with forward slashes back to DOS, DOS will puke. No it won't, because DOS has always accepted either forward or backslashes in pathnames. It converts them to backslashes internally, but accepts either, just like it accepts filenames in either upper or lowercase. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/53 BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
roberts@stsci.EDU (Jim Roberts) (06/24/91)
In article <13597@pt.cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: >No it won't, because DOS has always accepted either forward or backslashes >in pathnames. It converts them to backslashes internally, but accepts >either, just like it accepts filenames in either upper or lowercase. Not DOS 4.0x, which ruinously accepts only backslashes. I'm about to install 5.0. I suspect there is no improvement, but there hasn't been a posting in it yet here. It's a good idea to check out general assertions. -- Jim Roberts roberts@stsci.edu scivax::roberts
burleigh@ogre.cica.indiana.edu (Frank Burleigh) (06/24/91)
In <2815@nemesis.stsci.edu> roberts@stsci.EDU (Jim Roberts) writes: >In article <13597@pt.cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: >>No it won't, because DOS has always accepted either forward or backslashes >>in pathnames. It converts them to backslashes internally, but accepts >>either, just like it accepts filenames in either upper or lowercase. >Not DOS 4.0x, which ruinously accepts only backslashes. I'm about to >install 5.0. I suspect there is no improvement, but there hasn't been >a posting in it yet here. It's a good idea to check out general >assertions. i think ralf means that dos *functions* accept either fore or back slashes. they do indeed. for me, dos 4.01 at the command line won't accept '/' as it thinks that's a switch. natch. -- Frank Burleigh burleigh@cica.cica.indiana.edu USENET: ...rutgers!iuvax!cica!burleigh BITNET: BURLEIGH@IUBACS.BITNET Department of Sociology, Indiana University, Bloomington, Indiana 47405
sorrow@oak.circa.ufl.edu (06/24/91)
In article <PSHUANG.91Jun23155134@beeblebrox.mit.edu>, pshuang@athena.mit.edu (Ping-Shun Huang) writes: |>In article <0094A761.C2F6D640@MAPLE.CIRCA.UFL.EDU> sorrow@oak.circa.ufl.edu writes: |> |> > Finally, I need more help (yes, MORE help) on how to make my prompt use |> > forward slashes. Someone told me to intercept the DOS INT that returns |> > the correct working directory....is this safe? |> |>This would probably be a bad thing to do. Not dangerous per se, but it |>would almost certainly break a lot of programs. If you were to |>intercept the DOS service which returns the current working directory (I |>don't know which one it is off the top of my head) and return a modified |>string instead, your program may work the way you want. COMMAND.COM |>interpretation of the metacharacter "$P" in the PATH variable may work |>as you would want it. CD's default response when you don't give it a Disabled CD and wrote my own (support HOME environment variable to take you back to ~). |>any parameters would be consistent. However, any code which calls the |>DOS service not just to print to the screen, but to actually make use of |>the path returned thereafter (e.g. programs which switch the default |>directory while in operation, but are polite enough to save the |>directory you were in when you started it up) will break, because when |>they pass the path with forward slashes back to DOS, DOS will puke. Switchar should solve this. |>applications which do not go through DOS. Also, many programs may try |>to interpret any filenames you provide on the command line as a switch. I use switchar to get by the switch vs. directory path dilemma. /* Brian Hook -- Specialist in X to ANSI.SYS porting software ----------------------------------------------------------------- "Seamus, that's my dog...I saw her today at the reception...sorry, sixTEEN inches....better save the women and children first...but this one goes to 11! ..anymore of that plutonium nyborg?....there can be only ONE!....like a finger pointing to the moon....ease the seat back...one day closer to death */