uejio@lll-lcc.aRpA (Jeremy Y. Uejio) (02/12/88)
Hello all you MKS lovers! Does anyone know how to execute commands before exiting the login shell in MKS toolkit. I just bought the toolkit a few days ago and have a bunch of other questions about setting up the environment, speeding up access with a RAM disk, etc... I won't post these questions until I've played around a little more but the logout seems like an obvious yes here's how to do it or no, it can't be done. Thanks in advance, jeremy uejio uejio@lll-lcc.llnl.gov
wnp@dcs.UUCP (Wolf N. Paul) (02/15/88)
In article <1492@lll-lcc.aRpA> uejio@lll-crg.UUCP (Jeremy Y. Uejio) writes: >Does anyone know how to execute commands before exiting the >login shell in MKS toolkit. I just bought the toolkit a few >days ago and have a bunch of other questions about setting >up the environment, speeding up access with a RAM disk, etc... One way which works on my System V machine (and should thus also work with the toolkit, according to their manual) would be to put the following lines into /etc/profile: case "$0" in -sh) trap ". $HOME/logout.sh" 0 1 # $HOME/.logout on UNIX ;; esac (If you already have such a "case/esac" construct in there, just add the trap command under the "-sh" case, and make sure there is no other trap command disabling this later on). Then you just need to create a file $HOME/logout.sh (or $HOME/.logout on UNIX) for each user containing the commands you want executed on logout or hangup. The case statement makes sure that this trap gets set only in the login shell (subshells normally don't have an argv[0] beginning with a dash). Wolf Paul wnp@dcs.UUCP wnp@killer.UUCP
pam@hpbbse.HP.COM (Pierre-Alain Michel) (02/17/88)
Put the following in /etc/profile.ksh trap ` command1; command2 ` EXIT where command1, command2 are the commands you want executed on logout. Pierre-Alain MICHEL hpda!hpbbse!pam
waynec@hpsrli.HP.COM (Wayne Cannon) (02/17/88)
The MKS documentation explains where to put TSR's, etc. for each of their four configurations. Their first two configurations are run from DOS command.com prior to running the MKS shell /bin/sh.exe. If sh.exe is run from the config.sys file, the /etc/profile.ksh serves the same purpose as autoexec.bat does for DOS. If init.exe is run from the config.sys file, TSR's etc are started from /etc/rc.ksh. init will then prompt for a login and run whatever shell is specified for the user in /etc/passwd. I hope this answers your question. Wayne Cannon waynec@hpnmd.HP.COM (telco) (707)-577-3631
mja@whuts.UUCP (AMMANN) (11/05/88)
I'm having trouble running the MKS toolkit with MSC 5.1. when I try to do a simple compile - cl file.c - MSC comes back with error LINK : fatal error L1089: D: : cannot open response file . since I don't even want it to open a resonse file this leaves me a little confused. Any and all help will be appreciated. Matt Ammann att!whuts!mja
mbrands@idca.tds.PHILIPS.nl (Manfred Brands) (11/07/88)
The MKS shell acts strange in combination with Turbo Pascal 4.0 When I try to compile a program TPC is not able to find its configuration file. Normally the compiler searches for it in de same directory as the executable is in, using argv[0] on DOS 3.0 and up. The problem is, I suppose, that TPC only recognizes the backslash as a path separator and the MKS shell ALWAYS uses forward slashes. Even if I don't use the switch program to set the switch character. Ok, this problem can be solved by making an alias for TPC in which the options from the configuration file are given as command line options. Is it possible to tell the MKS shell to use backslashes instead, so that there is no compatibility problem with existing DOS programs ? But now the REAL PROBLEM !! The program generated by TPC is NOT executable under the MKS shell. When I type: program I get the message: program: Not executable BUT when I type: command /c program (or command -c program) the program runs normally. Does the MKS shell perform some checks on de .exe header to see whether a file is executable, and does TPLINK not fill in the correct values ? Please email me if you know what either TPC or SH do wrong. Manfred Brands mbrands@idca.tds.PHILIPS.nl
wheels@mks.UUCP (Gerry Wheeler) (11/08/88)
In article <4994@whuts.UUCP>, mja@whuts.UUCP (AMMANN) writes: > I'm having trouble running the MKS toolkit with MSC 5.1. > when I try to do a simple compile - MSC comes back with error > LINK : fatal error L1089: D: : cannot open response file. I think the problem here is related to the environment variables used by the compiler and linker. I have found I have to define these variables using backslashes instead of forward slashes. It seems the compiler and/or linker can't read a forward slash. Must need glasses. So, this is what I put into my profile.ksh: export INCLUDE="c:\mc\include" export LIB="c:\mc\lib" export TMP="c:\tmp" When I change these to use forward slashes, I get the error you describe. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
tneff@dasys1.UUCP (Tom Neff) (11/09/88)
I'm going to post this response instead of mailing it because I think it's a point all MKS users should remember. In article <4994@whuts.UUCP> mja@whuts.UUCP (AMMANN) writes: >I'm having trouble running the MKS toolkit with MSC 5.1. >when I try to do a simple compile - >cl file.c >- >MSC comes back with error >LINK : fatal error L1089: D: : cannot open response file >. >since I don't even want it to open a resonse file this >leaves me a little confused. >Any and all help will be appreciated. Keep in mind that 'cl' is a top-level shell which invokes compiler phases underneath it via DOS EXEC. There are two important differences between many MKS Toolkit setups and vanilla COMMAND.COM setups: the value of SWITCHAR and the value of COMSPEC. MKS recommends that you change your SWITCHAR to "-" (and provide switch.exe to let you do so on the fly) so that filename and switch syntax is more Unix-like; in addition, when SHELL=init.exe is specified, the COMSPEC environment variable is not automatically set to COMMAND.COM. (MKS's default setup files include a line to do this, but I'm not convinced everyone is completely careful about using the right files.) The SWITCHAR issue is the usual culprit. There are two ways programs can handle switches (either when parsing the ones passed to them, or when passing them to subprocesses): they can hard-code "/" as the assumed switch character, or they can ask DOS what the current SWITCHAR value is (via INT 21H service 57H) and use that. When the parent and child processes use different assumptions, trouble can result. For instance, and most seriously, COMMAND.COM itself uses the second "smart" method to look up the current SWITCHAR value. That is, if 'switch -' is in effect, the correct way to spawn a COMMAND-based subprocess is COMMAND.COM -C DIR *.C instead of the "/C" you would use if the default 'switch /' were in effect. So any program wishing to spawn something via COMMAND.COM *must* actually interrogate SWITCHAR first, if you want to be able to run it with 'switch -' in effect. Now, can you guess how many programs out there in the real world are smart enough to do this? That's right, you got it. :-) If you invoke COMMAND.COM with the wrong switch character, it interprets the {-|/}C as a filename argument, specifically the search PATH to be used for that invocation. (Now there's a little known fact, DOS buffs!) That's why you get all kinds of strange gunk with 'switch -' under MKS. My solution is just to set 'switch /' before running problem programs. It's not worth having 'switch -' inside an application. With MKS KSH aliases, you can "box" an application with 'switch' commands before and after, so retain the Unix syntax at the ksh prompt itself effortlessly. The COMSPEC problem is even simpler. Lots of programs *do* know to interrogate that environment variable and use it for the exact pathname of COMMAND.COM to spawn with. If you don't have it set, programs tend to croak when spawning. Disclaimer: I don't know for certain that either of these are Amman's particular problem. But the discussion may be of use to MKS users regardless.
wheels@mks.UUCP (Gerry Wheeler) (11/10/88)
In article <167@ssp2.idca.tds.philips.nl>, mbrands@idca.tds.PHILIPS.nl (Manfred Brands) writes: > When I try to compile a program TPC is not able to find its configuration > file. Normally the compiler searches for it in de same directory as the > executable is in, using argv[0] on DOS 3.0 and up. > The problem is, I suppose, that TPC only recognizes the backslash as a > path separator and the MKS shell ALWAYS uses forward slashes. Yes, the shell uses a forward slash when appending the command name to a part of the search path. So, even if your path is something like "\bin;\dos", argv[0] will look like "\bin/foo". > Ok, this problem can be solved by making an alias for TPC in which the > options from the configuration file are given as command line options. Or, make an alias for TPC which contains the full pathname using backslashes. That way, the shell will not have to use the PATH variable at all. For example, try something like: alias tpc="\bin\tpc.exe" > Is it possible to tell the MKS shell to use backslashes instead, so that there > is no compatibility problem with existing DOS programs ? Sorry, no. > The program generated by TPC is NOT executable under the MKS shell. > > When I type: > program > > I get the message: > program: Not executable I haven't heard about this before. Can you email me a copy of a small executable that shows this problem? -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043 -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
wheels@mks.UUCP (Gerry Wheeler) (11/11/88)
In article <7501@dasys1.UUCP>, tneff@dasys1.UUCP (Tom Neff) writes: > So any program wishing to spawn something via COMMAND.COM > *must* actually interrogate SWITCHAR first, if you want to be able > to run it with 'switch -' in effect. Now, can you guess how many > programs out there in the real world are smart enough to do this? > That's right, you got it. :-) Microsoft's own system() library function fails on this count. If you write a program in Microsoft C using the system() call, it calls command.com with the "/c" option without checking the current switch character. I think Microsoft is moving away from allowing the use of hyphen as the switch character. In DOS 4.0, it appears that most DOS utilities (command.com, format, etc.) do not check the current setting of the switch character. I sometimes wondered if the system call to set/retrieve the switch character was put in by a Unix programmer without permission to do so, and they're still getting rid of his code. :-) -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
jes@eniac.seas.upenn.edu (Joe Smith) (11/12/88)
In article <546@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: >Microsoft's own system() library function fails on this count. If you >write a program in Microsoft C using the system() call, it calls >command.com with the "/c" option without checking the current switch >character. > But there is a fix for this of course. Extract the system.obj from the library. Use debug to patch the object file, change to /c to a -c which command.com will accept (actually require under DOS 3.1) and then replace the system() library function with the patched version. Then you have a functional system() with a -c. Frank Kolakowski ____________________________________________________________________________ |c/o jes@eniac.seas.upenn.edu || Univ. of Penna. | |kolakowski%c.chem.upenn.edu@relay.upenn.edu || Dept of Chemistry | |bcooperman.kolakowski@bionet-20.arpa || 231 South 34th St. | |AT&T: 1-215-898-2927 || Phila, PA 19104 | ============================================================================= Joe Smith jes@eniac.seas.upenn.edu University of Pennsylvania Department of Chemistry 231 S. 34th Street Philadelphia, PA 19104 (215) 898-4797
treed@dasys1.UUCP (Timothy Reed) (11/14/88)
In article <545@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: >In article <167@ssp2.idca.tds.philips.nl>, mbrands@idca.tds.PHILIPS.nl (Manfred Brands) writes: > > alias tpc="\bin\tpc.exe" > Similarly, Word Perfect 5.0 chokes on the directory separator too - I had to escape the '\' though, to call WP from any directory: alias wp="\\wp50\\wp" unrelated query: the Turbo C TSR help utility, 'THELP.EXE', disappears when run by init - it also takes up too much ram than advertised when started by the toolkit. I've received mail on compuslave from others that have experienced the same problem. Any reason as to why this happens, Gerry? When I boot up with command.com as my interpreter, and then start up /bin/sh, the same amount of ram is used as when /bin/sh is the startup shell, about 175 KB. Why is that? Timothy Reed uunet!dasys1!treed
wheels@mks.UUCP (Gerry Wheeler) (11/15/88)
In article <7635@dasys1.UUCP>, treed@dasys1.UUCP (Timothy Reed) writes: > The Turbo C TSR help utility, 'THELP.EXE', disappears > when run by init. > Any reason as to why this happens, Gerry? Not yet, but I'm looking into it. From the messages I saw on Compu$pend, the problem is that the file is removed from the disk. Sounds weird to me, but I'll let you know more when I get into it. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
tneff@dasys1.UUCP (Tom Neff) (11/15/88)
In article <6139@netnews.upenn.edu> jes@eniac.seas.upenn.edu.UUCP (Joe Smith) writes: -In article <546@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: ->Microsoft's own system() library function fails on this count. If you ->write a program in Microsoft C using the system() call, it calls ->command.com with the "/c" option without checking the current switch ->character. - -But there is a fix for this of course. - -Extract the system.obj from the library. -Use debug to patch the object file, change to /c to a -c -which command.com will accept (actually require under DOS 3.1) -and then replace the system() library function with the patched version. - -Then you have a functional system() with a -c. And ONLY with -c, which is just as bad as the original. What you want is to be able to run with either switch character. If you are developing your own code, you can write a front end for system() if you want, that saves the current switch character and temporarily sets it to '/' before falling thru to system(), then restores the prior value on return. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
tneff@dasys1.UUCP (Tom Neff) (11/15/88)
This might be a good time to remind MKS Toolkit users of one of my
favorite tips. If you have ANY trouble loading TSRs under init.exe
but you still want to convenience of the full "configuration 4" MKS
setup, do this: Set SHELL=COMMAND.COM in your CONFIG.SYS, and create
an AUTOEXEC.BAT that loads all your TSRs. Then let the last line in
AUTOEXEC.BAT be "\bin\init.exe". This will pick up smoothly with
the MKS load process; your /etc/rc file doesn't contain any TSR
loads under this scheme, only one-shot commands (which you can also
move to AUTOEXEC if you want, like "MODE COM1:9600" etc) and the
important "respawn login" line.
The penalty for keeping that resident COMMAND.COM copy around is
only a few K. The benefits are trouble free TSR operation and no
lame explanations when you call a vendor's tech support line ("Uh,
no, actually, I'm not running COMMAND.COM at all, see... :-)").
--
Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff
"None of your toys CIS: 76556,2536 MCI: TNEFF
will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)ssa@mrsvr.UUCP (Shahrooz S. Alavi) (11/17/88)
From article <7635@dasys1.UUCP>, by treed@dasys1.UUCP (Timothy Reed): > In article <545@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: >>In article <167@ssp2.idca.tds.philips.nl>, mbrands@idca.tds.PHILIPS.nl (Manfred Brands) writes: >> ... > Similarly, Word Perfect 5.0 chokes on the directory separator too - I had > to escape the '\' though, to call WP from any directory: I use procomm plus with MKS toolkit and it did not like the / as the directory seperator. So what I did is I made up a file called pcplus.ksh which contained the following three lines: switch / pcplustd switch - These lines obviously work if the file name was .bat ======================================================================= / /| | |\ \ | | /__ /_| | |_\ \ | | ...att!uwmcsd1!mrsvr!ssa / / | | | \ \ | | (414) 547-9429 / o / | |__ | \ \| | (414) 521-6607 (work) =======================================================================
cnee@wright.EDU (Cheng-Lee Nee) (03/30/89)
Recently, I have read some discussions on the net concerning the MKS Toolkit. As far as I know, there is a c-shell clone included in the kit. My question is: Is it run on top of the COMMAND.COM or as a replacement? How much free RAM (out of 640K) would left after loading the shell (or anything else)? I'd really like to purchase a copy of the Toolkit but I am using some software that requires 512K free RAM. If the Toolkit can't fit my needs, I'll have to stick with the PiCnix. Thanks in advance. Cheng-Lee Nee cnee@thor.wright.edu
lfk@mbio.med.upenn.edu (Lee Kolakowski) (03/30/89)
In article <465@thor.wright.EDU> cnee@wright.EDU (Cheng-Lee Nee) writes: > As far as I know, there is a c-shell clone included in > the kit. No, not a c-shell (csh) clone, but a korn shell look-alike. > My question is: Is it run on top of the COMMAND.COM or as > a replacement? You have choices here. you can run a program called init which spawns a ksh for your login, or use the shell as your boot shell, or run it on top of command.com. > How much free RAM (out of 640K) would left after > loading the shell (or anything else)? Here is the output of my system's ps command (process status) Size is the size of memory in paragraphs $ ps PID PPID SIZE DS Command 205c 9ded 0268 21b9 ? <-- Init and device drivers 22c5 205c 0001 22c7 FREE 0001 22c9 2654 0004 22ce 205c 0385 274b ? /D:PRN /Q:32 /B:8000 <--- MSDOS print 2654 205c 0186 2654 c:/usr/bin/spool.com <--- A dumb little spooler 27db FREE 0002 27de 205c 0810 27ee c:/bin/ksh.exe -R 0 <--- korn shell (this version 2fef 301d 002d loads the text segment 301d 27de 029b 31ae c:/bin/ps.exe high in memory and reloads 32b9 FREE 6d3c <--\ when needed) 9ff6 27de 000a \---------- Free memory $ mem mem: 498592 bytes free out of 655360 bytes $ cat /config.sys buffers=30 # Uncomment this next line if you want TEK 4010 files=20 # device driver installed break=on # device=\dev\plot.dev -g0 -c0 -p0 -v0 -t0 -d0 -s1 stacks=0,0 # device=\dev\himem.sys -hmamin=0 # device=\dev\fconsole.dev -l=1 -g=400 -s=5000 -q=1 -r=100 device=\dev\edvr.sys # device=\dev\ramdriver.sys 384 1024 400 /e shell=C:\etc\init.exe I can get as much as 590 K free memory without the spoolers and without fasni-console. -- Frank Kolakowski ____________________________________________________________________________ |lfk@mbio.med.upenn.edu || Lee F. Kolakowski | |kolakowski@mscf.med.upenn. || Univ. of Penna. | |c/o jes@eniac.seas.upenn.edu || Dept of Chemistry | |kolakowski%c.chem.upenn.edu@relay.upenn.edu || 231 South 34th St. | |kolakowski%d.chem.upenn.edu@relay.upenn.edu || Phila, PA 19104 | |bcooperman.kolakowski@bionet-20.arpa ||--------------------------| |AT&T: 1-215-898-2927 || One-Liner Here! | =============================================================================
pyt@hprnd.HP.COM (Pierre-Yves Thoulon) (03/31/89)
> Recently, I have read some discussions on the net concerning the > MKS Toolkit. As far as I know, there is a c-shell clone included in > the kit. It's actually a K-shell clone. > My question is: Is it run on top of the COMMAND.COM or as > a replacement? As you like. I have thrown away COMMAND.COM and specified the MKS shell in my config.sys. > How much free RAM (out of 640K) would left after > loading the shell (or anything else)? On my system I get roughly 480K. I start some TSR's before my shell and haven't really played enough with it to tell whether I could gain the extra 30K you need. Note that the Toolkit offers an exec command that allows you to replace the shell with the program you want to execute, instead of creating a child. This might free up the memory you need. I haven't tried this so I can't really tell. Pyt.
gph@hpsemc.HP.COM (Paul Houtz) (03/31/89)
cnee@wright.EDU (Cheng-Lee Nee) writes: >Recently, I have read some discussions on the net concerning the >MKS Toolkit. As far as I know, there is a c-shell clone included in >the kit. My question is: Is it run on top of the COMMAND.COM or as >a replacement? How much free RAM (out of 640K) would left after >loading the shell (or anything else)? I'd really like to purchase a >copy of the Toolkit but I am using some software that requires 512K >free RAM. If the Toolkit can't fit my needs, I'll have to stick >with the PiCnix. I just bought MKS Toolkit a week ago. It has a Korn shell (not c-shell) included, and it can run either on top of COMMAND.COM or in place of it. I have my machine set up so that you can login and get COMMAND.COM or KORN SHELL. You just put COMMAND.COM in the /etc/passwd file at the end of the login entry. I have no idea how much memory it takes, but it seems significant. What is PiCnix? Paul Houtz HP Technology Access Center 10670 N. Tantau Avenue Cupertino, Ca 95014 (408) 725-3864 hplabs!hpda!hpsemc!gph gph%hpsemc@hplabs.HP.COM
vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (03/31/89)
In article <1040012@hprnd.HP.COM> pyt@hprnd.HP.COM (Pierre-Yves Thoulon) writes: >Note that the Toolkit offers an exec command that allows you to replace >the shell with the program you want to execute, instead of creating a >child. This might free up the memory you need. I haven't tried this >so I can't really tell. I do this regularly. I have an 'alias exdos="exec command.com"', and when I'm tight it works just fine, freeing up the 70K+ differential between ksh and command.com. When I then EXIT from DOS again, ksh reloads itself. Also, on ^D or 'exit' from ksh, any TSRs loaded after loading ksh itself (i.e. not loaded by /etc/inittab before ksh), are wiped from memory. Very convenient. -- O----------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large | Systems Science, SUNY Binghamton, vu0112@bingvaxu.cc.binghamton.edu V All the world is biscuit shaped. . .
ked@garnet.berkeley.edu (Earl H. Kinmonth) (04/01/89)
In article <465@thor.wright.EDU> cnee@wright.EDU (Cheng-Lee Nee) writes: >Recently, I have read some discussions on the net concerning the >MKS Toolkit. As far as I know, there is a c-shell clone included in Anyone who would look for C-shell clone under MSDOS must be the kind of person who would look for way to merge his Edsel and VW bug! MKS offers a very reasonable Korn (ksh) shell for MSDOS (and Xenix). Overall, its a bit like fuel injecting an Edsel. On the one hand, you have to admire the technical expertise. On the other hand, you have to wonder, "Gee, just think what they could have done with a Porsche!" Disclaimer: I bought MKS out of pocket. The value/buck is, in my opinion greater than any other piece of MiSerable DOS software, bar none.
wnp@killer.Dallas.TX.US (Wolf Paul) (04/01/89)
Recently, ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: | |Anyone who would look for C-shell clone under MSDOS must be the kind of |person who would look for way to merge his Edsel and VW bug! | |MKS offers a very reasonable Korn (ksh) shell for MSDOS (and Xenix). |Overall, its a bit like fuel injecting an Edsel. On the one hand, you |have to admire the technical expertise. On the other hand, you have to |wonder, "Gee, just think what they could have done with a Porsche!" | That's right, but how many working-class people do you know who can afford to drive a Porsche? Similarly, there are a lot of folks out there who have no choice regarding the machines or O/S to use; all they can do is put some piece of software on top of their hard- and software platform to make it a little less awkward to use. And if a person is more familiar with CSH than with SH or KSH, that's what he'll be looking for to make his MS-DOS environment more easy to use. Speculation on what type of person that would be is silly and unnecessary, on a par with the periodic, idiotic "editor wars". -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!wnp ESL: 62832882 DOMAIN: wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
max@jma.UUCP (Max Heffler @ Landmark Graphics) (04/02/89)
I have converted my at to run under the MKS toolkit. Before MKS, my ZAP program would dial the number listed in the ZAP.ENV file, but now the atdt sequence is echoed but not dialed. I then must dial it manually. Does anybody have an idea of what I need to repair? Thanx in advance.` -- Max Heffler uucp: ..!uunet!jma!max Landmark Graphics Corp. phone: (713) 579-4751 333 Cypress Run, Suite 100 Houston, Texas 77094
) Seaman) (04/04/89)
In article <1040012@hprnd.HP.COM>, pyt@hprnd.HP.COM (Pierre-Yves Thoulon) writes: < > Recently, I have read some discussions on the net concerning the < > MKS Toolkit. As far as I know, there is a c-shell clone included in < > the kit. < It's actually a K-shell clone. This may seem like picking nits, but I just wanted to say (for the benefit of those considering the MKS Toolkit) that the sh.exe provided is NOT a clone of the Korn shell, it IS the Korn shell, meaning that it is a fully licensed version, and is considered (by David Korn) to be an official PC implementation. At least that is the way he mentions it in his book on KSH. < > My question is: Is it run on top of the COMMAND.COM or as < > a replacement? < As you like. I have thrown away COMMAND.COM and specified the MKS shell < in my config.sys. You can also run an MKS version of init, that actually uses an inittab file, and can spawn a 'login' process, which gives the capability of running command.com, ksh, or directly logging into an application. The overhead of init is about 10K, but login dies after 'execing' the program specified in (you guessed it) /etc/passwd. I've been using it for about a year and a half, with no trouble at all. < > How much free RAM (out of 640K) would left after < > loading the shell (or anything else)? < On my system I get roughly 480K. I start some TSR's before my shell and < haven't really played enough with it to tell whether I could gain the < extra 30K you need. You can also load TSR's through the inittab (mentioned above), before loading login (or shell, or command.com, or ...). The actual amount of memory used by the shell varies, depending on how you configure it, but the minimum is (to the best of my recollection) 77K. NOTE: I have no connection with MKS other than as a very satisfied customer, etc.... -- Chris Seaman | o\ /o crs@cpsc6a.att.com <or> | || See "Attack of the Killer Smiley"! ..!ihnp4!cpsc6a!crs | \vvvvvv/ Coming Soon to a newsgroup near you! | \____/
psfales@ihlpb.ATT.COM (Peter Fales) (04/04/89)
In article <2031@bingvaxu.cc.binghamton.edu>, vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: > I do this regularly. I have an 'alias exdos="exec command.com"', and > when I'm tight it works just fine, freeing up the 70K+ differential > between ksh and command.com. When I then EXIT from DOS again, ksh > reloads itself. Also, on ^D or 'exit' from ksh, any TSRs loaded after > loading ksh itself (i.e. not loaded by /etc/inittab before ksh), are > wiped from memory. Very convenient. With all the talk about memory size under ksh, I wonder if someone else could confirm the results of a test I made. I wanted to find out how much memory I saved running with /etc/init as my shell and using the init/login/ksh process rather than booting command.com and invoking ksh, so I tried it both ways. I don't remember the exact numbers, but assuming I did the experiment correctly, there was almost no difference between the two. This pretty much cured me of any further desire to use init/login. I assume this is because the transient portion of command.com is being discarded and the resident portion is comparable in size to init.exe. Any gurus out there to confirm or deny? -- Peter Fales AT&T, Room 5B-414 2000 N. Naperville Rd. UUCP: ...att!ihlpb!psfales Naperville, IL 60566 Domain: psfales@ihlpb.att.com work: (312) 979-8031
maddog@cbnews.ATT.COM (john.j.tupper) (04/04/89)
In article <131@jma.UUCP> max@jma.UUCP (Max Heffler @ Landmark Graphics) writes: >I have converted my at to run under the MKS toolkit. Before MKS, >my ZAP program would dial the number listed in the ZAP.ENV file, >but now the atdt sequence is echoed but not dialed. I then must dial >it manually. Does anybody have an idea of what I need to repair? In unix, echo is terminated with a new line character (line feed to the rest of the world). Hayes modems need a carriage return before they recognize a command. So, you could try: echo "ATDTmumble\r\c" The \r gives you a carriage return and the \c suppresses the line feed. [If you're now using a shell script to dial your modem, then never mind. . .] ---------------------------------------------------------------------------- sdfkj slkdoiwe sd my real signature is illegable too
max@jma.UUCP (Max Heffler @ Landmark Graphics) (04/06/89)
In article <5368@cbnews.ATT.COM>, maddog@cbnews.ATT.COM (john.j.tupper) writes: > In article <131@jma.UUCP> max@jma.UUCP (Max Heffler @ Landmark Graphics) writes: > >I have converted my at to run under the MKS toolkit. Before MKS, > >my ZAP program would dial the number listed in the ZAP.ENV file, > >but now the atdt sequence is echoed but not dialed. I then must dial > >it manually. Does anybody have an idea of what I need to repair? > > In unix, echo is terminated with a new line character (line feed to the rest Actually, I repaired it last night, mostly. I had both transmit and redial lines. When I use either one with \0d (Carriage return) it works; however, I can not get the user name/passwd taken using that option of redial. Any ideas? Again, Thanx in advance -- Max Heffler uucp: ..!uunet!jma!max Landmark Graphics Corp. phone: (713) 579-4751 333 Cypress Run, Suite 100 Houston, Texas 77094
mshiels@tmsoft.uucp (Michael A. Shiels) (04/07/89)
With the RAM crunch problem there are a few things MKS can do (Are you listening MKS people!) Swap the shell to EMS ram when running a sub program or keep it there. Or swap it to ram disk. All the large software I write can swap everything but 4K to disk for processing command.com subshells.
alex@mks.UUCP (Alex White) (04/11/89)
In article <505@cpsc6b.cpsc6a.att.com>, crs@cpsc6b.cpsc6a.att.com (Chris (I'm Outta Here!) Seaman) writes: > This may seem like picking nits, but I just wanted to say (for the benefit > of those considering the MKS Toolkit) that the sh.exe provided is NOT a clone > of the Korn shell, it IS the Korn shell, meaning that it is a fully licensed > version, and is considered (by David Korn) to be an official PC > implementation. At least that is the way he mentions it in his book > on KSH. NO! This is FALSE. The sh.exe included in the MKS Toolkit is a *clone* of the Korn Shell. It has been independently developed entirely from scratch here at MKS. It is *not* licensed from AT&T. I have just looked up what Korn says in his book: "... An MS-DOS version of the KornShell is available from Mortice Kern Systems, Inc. of Waterloo, Ontario in Canada." I guess from that sentence you could indeed get the wrong impression. I'm actually surprised that AT&T let him put that sentence in the book -- when "The AWK Programming Language" by Aho, Kernighan, Weinberger came out, AT&T said there was no way we could even be mentioned because they hadn't evaluated our awk, and didn't want to be seen in any way as endorsing it. If you tick off ``MS-DOS'' on the tear off card in the back of the book, Addison-Wesley forwards the card on to us. I really don't know why thats any different myself, but lawyers will be lawyers. And in case you are wondering, yes MKS AWK is a *clone* completely re-written from scratch. There is no utility in the MKS Toolkit which is licensed from AT&T. We have written them all from scratch to avoid any licensing problems. (Well almost all. YACC was actually done at the local university (University of Waterloo) and we license it from them.) Alex White An owner of MKS So I ought to know.