Help with SWITCHAR
Fred Hollander
to enter the editor by typing 'e'. It works fine but, when I add the line:
switchar=-
to my config.sys file, trying to enter the editor from more causes the error:
Specified COMMAND search directory bad
and doing a set shows that PATH is empty and COMPSPEC is the only other
environment variable set.
I've tried setting the SHELL in the config.sys file and changing the PATH
to use '/' instead of '\' but, I've had no luck.
Does anybody know what the problem might be?
Thanks for your help,
Fred Hollander
Penn State
Donald L. Nash
The problem is probably that the program does not check to see what the
what the SWITCHAR is before trying to run the editor. If it runs the
editor by calling up command.com like this:
command /c editor
then changing SWITCHAR will blow its mind. I've had the same thing
happen to me when using Kermit. I had changed the SWITCHAR to '-' and
then tried to get a directory listing from Kermit. I had the same
results, since Kermit would try to do the following:
command /c dir
The only solution is not to change the SWITCHAR, since most programs
don't check for it. However, if you find using '/' very unsatisfactory,
then that is not much of a solution....
Don Nash
UUCP: ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!dlnash
APRA: dln...@ngp.UTEXAS.EDU
BITNET: cceu001@utadnx
Tony Movshon
but have now solved.
> ... when I add the line:
> switchar=-
> to my config.sys file, trying to enter the editor from more causes
> the error:
> Specified COMMAND search directory bad
> Does anybody know what the problem might be?
>
> Fred Hollander
> Penn State
The problem is this: when a DOS program executes a sub-process via the
command interpreter, it uses the system LOADEXEC function with an argu-
ment string like
"command /c commandname"
The "/c" switch tells the exec'ed version of command to run the process
and then exit. If you are hooked on using the Un*x-like "-" as a switch
character, the command processor interprets the "/c" not as a switch but
as an argument, and complains. The solution is to use the DEBUG program
to find all instances of "command /c" (or "COMMAND /C", or whatever case
combo the programmer may have liked) and replace the "/" with "-". Note
that after you do this, the resulting program will not run unless the
switch character has been redefined.
What programs should do, of course, is use the (undocumented) DOS function
37H to determine the current switch character, and compile the command
string correctly. This is done by some but not all DOS system programs,
and a few applications. Example code to do this (contributed by yours
truly) can be found in releases of MS-Kermit V2.27 or later; it is not
very complicated.
Incidentally, the declaration of SWITCHAR is no longer allowed in DOS 3.x,
but you can still use function 37H to set the switch character to your
liking. There is a small public-domain program called SWCHAR around which
does this; I will repost it if there is enough demand.
Tony Movshon
Psychology/NYU
uucp: {seismo|ihnp4|allegra}!cmcl2!acf8!movshon
arpa: movshon@acf8
Ross Greenberg
Oh well....I've hit the same problem, alas. It stems from code trying
to execute a program called "COMMAND/C". If switchar=- is set, then the
program "COMMAND/" is attempted to be executed, eventually falling flat
on its face.
The only solution I've found is a choice between two uglies:
1) Create a program that switches back and forth the switchar
via DOS interrupt 0x21 with AH=0x37.
2) Debug the code in question, do a search for the '/C' and
replace it with a '-C'.
When will people learn to check the real environment before making
assumptions? <Sigh>....
--
------
ross m. greenberg
ihnp4!allegra!phri!sysdes!greenber
[phri rarely makes a guest-account user a spokesperson. Especially not me.]
R.D.Eager
>to execute a program called "COMMAND/C". If switchar=- is set, then the
>program "COMMAND/" is attempted to be executed, eventually falling flat
>on its face.
>
>The only solution I've found is a choice between two uglies:
>1) Create a program that switches back and forth the switchar
> via DOS interrupt 0x21 with AH=0x37.
>2) Debug the code in question, do a search for the '/C' and
> replace it with a '-C'.
>
>When will people learn to check the real environment before making
>assumptions? <Sigh>....
>
be there) which means the guy who wrote the program either:
- didn't know about it
- made a conscious decision not to use it in the interests of forwards
compatibility.
--
Bob Eager
r...@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589
gl...@anasazi.uucp
>to enter the editor by typing 'e'. It works fine but, when I add the line:
> switchar=-
>to my config.sys file, trying to enter the editor from more causes the error:
> Specified COMMAND search directory bad
Most programs which allow you to run other programs from within usually use some
variation of the dos exec (dos call 41B)to spawn off another copy of
command.com that would look like this (that is if you entered if from
the dos prompt):
C> command edt /c
Now, most C compilers do not look for the SWITCHAR variable when building up
this text string and blithely put in /c. Thus, the problem is that when you
redefine switchar, '/' becomes a path spec, not an argument character, and
thus screws up command.com.
The solution? Rewrite your C compiler's exec call to check the SWITCHAR
variable when doing an exec.
Glenn Ehrlich
International Anasazi
Phoenix, AZ
Ross Greenberg
>>[Quoting me attacking various software products and their incompatibilities
>>with variou settings of SWITCHAR]
>Hardly fair. This is an undocumented feature
> (however much we believe it should
>be there) which means the guy who wrote the program either:
> - didn't know about it
> - made a conscious decision not to use it in the interests of forwards
> compatibility.
That would be the case, except that the program in question seems to
be a compiler. I would expect compiler designers to keep current on
even undocumented features -- part of the joys of working for a large
software house, I feel.
The code in question (fetch the switchar and replace it in the call
to LOAD AND EXECUTE) is only a few bytes long. We've been talking about
the switch character on the net for about a year now, and *our* code
allows for it. Documented or not, the compiler author(s) must have
received a number of calls about it, and therefore should have been
able to determine what the problem is/was and fixed it.
Just my opinion, of course!
Steve Tell
>to execute a program called "COMMAND/C". If switchar=- is set, then the
>program "COMMAND/" is attempted to be executed, eventually falling flat
>on its face.
>When will people learn to check the real environment before making
>assumptions? <Sigh>....
It would help the situation very much if this call were
documented by IBM in their otherwise decent "Dos Technical Reference
Manual"
Instead of saying "Function 37h: Reserved for DOS"
How many other "Reserved for DOS" functions would be of
use to everyone?
Listening IBM, Microsoft, and other makers of software?
Ross Greenberg
[Taking about the Internal Switchar Function]:
>
>It would help the situation very much if this call were
>documented by IBM in their otherwise decent "Dos Technical Reference
>Manual"
>Instead of saying "Function 37h: Reserved for DOS"
>
>How many other "Reserved for DOS" functions would be of
>use to everyone?
>
Well...I suppose it's time to post the Undocumented Interrupt List
I've had for a while.
The pity is, the updates were lost when the last machine they were
on (timeinc) bit the dust. So I only have the original.
It's pretty big, so I'm hesitant to post it unless there's enough
interest: if enough people mail a "please send me a copy", I'll
post. Otherwise I'll UUCP mail it out to ya.
Mike Farren
>
>Well...I suppose it's time to post the Undocumented Interrupt List
>I've had for a while.
>
Well...if so, it's probably time for me to repeat my warning, given
so many times before, in so many places:
*** THERE'S A REASON THESE ROUTINES ARE UNDOCUMENTED ***
Especially with PC-DOS (as opposed to MS-DOS), the routines which are
undocumented are so because: 1) They may not be around in the next
iteration of DOS, and therefore may guarantee incompatibility with later
versions. 2) They don't work correctly for general purposes. A prime
example of this is the "indos" function, which supposedly told you when
it was safe to call DOS functions from interrupt handlers. Problem is,
it doesn't ALWAYS work, and if a function like this EVER fails, you're
in deep crud.
I'm not saying that you should NEVER use undocumented routines, as
sometimes they can let you accomplish things impossible to do without
them. You should always be aware of the pitfalls, though!
--
Mike Farren
uucp: {your favorite backbone site}!hplabs!well!farren
Fido: Sci-Fido, Fidonode 125/84, (415)655-0667
Chuck Forsberg WA7KGX
>[Taking about the Internal Switchar Function]:
>>
>>It would help the situation very much if this call were
>>documented by IBM in their otherwise decent "Dos Technical Reference
>>Manual"
>>Instead of saying "Function 37h: Reserved for DOS"
>>
>>How many other "Reserved for DOS" functions would be of
>>use to everyone?
Seems like the more recent versions of MS link have stopped looking at
the SWITCHAR function. This may be a sign that SWITCHAR support is on its
way out.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131
Author of Professional-YAM communications Tools for PCDOS and Unix
Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly
hol...@psuvax1.uucp
>
> Well...I suppose it's time to post the Undocumented Interrupt List
> I've had for a while.
>
Sorry for the followup, but the mail keeps coming back...
If you don't post the list, would you please send me a copy?
Thanks,
Fred Hollander
Penn State
hol...@psuvax1.bitnet
J. Eric Roskos
>
> I'm gonna post it shortly. There were over 75 requests!!!
There were more than that... as one who also wrote but couldn't get
through, and who is also responsible for mail ("postmaster") at one of
the paths to phri, I can tell you that there have been several dozen
messages addressed to phri!greenber that went through here, followed
a little later by messages going the other way from MAILER-DAEMON@phri...
so, unless you also posted something that provoked a lot of flames :-),
I'll bet there are over a hundred people who wrote. (There must be
two phri's, or something.)
(I would have mailed this, but I've tried every path I could find to phri.)
--
E. Roskos
"It's Halley's comet!"
jd...@ur-tut.uucp
>> To those that sent me mail regarding the Interrupt List:
>>
>> I'm gonna post it shortly. There were over 75 requests!!!
>
>There were more than that... as one who also wrote but couldn't get
>through, and who is also responsible for mail ("postmaster") at one of
>the paths to phri, I can tell you that there have been several dozen
Has someone already posted this list sometime in the past few weeks?
If so, could they mail it to me?
Otherwise, if it hasn't been posted, why not quit talking about it and
POST IT!!! PLEEEEEEAAAAAASSSSSE!!!
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Wowbagger:
...seismo!rochester!ur-tu!jdia
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\