Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 20.07.2014 23:20, schrieb perditi...@gmail.com: On Sun, Jul 20, 2014 at 2:53 PM, Eric Auer e.a...@jpberlin.de mailto:e.a...@jpberlin.de wrote: Hi Juan, ... Please note I am very happy to know that this issue has already been fixed but as a newbie to FreeDOS is it of no practical use to me to know that the fix is in some local GIT repository. As a newbie or average FreeDOS user I assume Jeremy has some daily build style pre-compiled kernels and command.com http://command.com that you can download somewhere? ... Compiled kernels from my git source in both standalone and fdpkg formats including source archive. http://www.fdos.org/kernel/testing/git/ This is a fairly stable location and referenced in my github page (https://github.com/PerditionC/fdkernel). I have a temporary* build of FreeCom at http://www.fdos.org/kernel/command/FreeCom/test/ * where temporary means will be there until a newer version with a fix is released or I otherwise don't see it as needed or I redo my site Jeremy -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel OFYI, I have tried the fixed kernel and reading from the NULL device works now. The new command.com still fails in the same way as described before. Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 20.07.2014 20:53, schrieb Eric Auer: Hi Juan, It is still not fully clear to me how different DOS differs regarding the arguments passed to batch situation... Even if 4DOS solves it, what exactly is the difference in style? May be that the most important issue here is to understand that we are talking about command line arguments of a _batch file_ and we are _not_ talking about command line arguments for a dos program like xcopy.exe or command.com or what ever else shell is used. AFAIK at least for MSDOS 6.22 the only valid argument switch or separating chars are the following ones: space (space also means tab). semicolon ; comma , equal sign = Every of these chars are de-facto replaced by a single space and do limit the argument that may precede or follow it. Neither slash nor backslash nor colon nor question mark are usually separation chars. I do not even know if they are allowed at all. If I start the sample batch file I send in my very first posting like this: test.bat /q/w/e/r/t/z I will get the following output on MSDOS 6.22: test.bat /q/w/e/r/t/z finished with arguments The same applies to the command.com versions of Win98SE and WinXP. Please note that there are neither quoting nor spaces before any of the slashes. Now I start the batch file like this (again MSDOS 6.22): test.bat /q/w=/e/r=/t/z and I get the following output: test.bat /q/w /e/r /t/z finished with arguments Again no quoting but this time I have inserted equal signs so that the initial sequence has become split into 3 different arguments. If I do the same with stock FreeDOS 1.1 distribution I get the following output: test.bat /q /w= /e /r= /t /z finished with arguments I do not want to bore the people here with this issue any more. I can fix it either using 4dos or by telling the user to quote the arguments. [snip] 1) The read from NUL bug. Yes this is a bug due to 2 reasons. a) If a command like this: program.exe NUL is not forbidden it is allowed. AFAIK, microsoft has not published any documentation that states that reading from NUL is not defined. b) If it works with microsoft dos kernels it should work with FreeDOS So what is the desired behaviour of program.exe NUL and what is the current FreeDOS behaviour? I remember that the topic had some ambiguity but I think as long as it is not breaking something else, mimicking Microsoft sounds better. IMHO it should work as MSDOS works. But this is now the case, it has been fixed. Please see: http://sourceforge.net/p/freedos/mailman/message/31764688/ The only reason why I had mentioned that issue again, was the fact that I did not known how to get a copy of the fixed kernel. But now I know how to get a fixed kernel and a fixed FreeCom. I will give it a try the next days. [snip] Please do not get me wrong but all this is not an inconvenience to me. But it may become an inconvenience for a newbie or even average DJGPP user. I have been porting GNU software to DOS using DJGPP since at least 8 years and joined the DJGPP developer group even a couple of years before. When Rugxulo uploads a port of bzip2 or lua to http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files he uploads ports that I have produced and made available at ftp.delorie.com. So again, I have a very fine working environment to produce software packages using DJGPP. But what shall I tell an user that asks me what OS he shall use to compile the sources of the ports I am making available? I have to admit that during all my years of porting I have never cared about FreeDOS. I have done all developing work on WinXP and not checked the port with any other OS. Again if an user asks me what OS shall he use to compile some port sources, shall I tell him, go to ebay and buy WinXP or shall I tell him to give FreeDOS a chance? To recommend FreeDOS I must be able to configure and compile every single port I have released over the years. The very first step to configure the source of a port is to cd into the building directory usually called either _build.204 or _build.203 and from there start the batch file that will configure the sources. This batch file located in the /djgpp directory must be started like this: ..\djgpp\config.bat ./.. [and all the other optional arguments] The first argument, and this argument cannot be omitted, is the unix-style path to the sources. The path may be followed by optional arguments. It becomes clear that this batch file will not work correctly with the current FreeDOS distribution due to the FreeCom behavior that strongly deviates from command.com and cmd.exe behavior. The observation of this different behavior was my initial and only motivation to send the first posting that initiated this thread. Regards, Juan M. Guerrero -- Want fast and
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 12:43, schrieb Rugxulo: Hi, On Sat, Jul 19, 2014 at 12:00 AM, Mateusz Viste mate...@viste.fr wrote: I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. sed can use other delimiters, if slash is too prohibitive. Sometimes that makes things easier to read and write. Just for silly example (tested under Cygwin): echo $PATH | sed -e '/.*\(\/cygdrive\/c\/rugxulo\/watcom19\/BINNT\).*/s//\1/' ... vs. ... echo $PATH | sed -e '\,.*\(/cygdrive/c/rugxulo/watcom19/BINNT\).*,s,,\1,' Oops. Or did you mean that this bug in FreeCOM might break sed invocations? I doubt it, the double quotes after -e probably protect it from munging. No, this is not a sed issue. The issue I reported concerns the treating of the arguments passed to a batch file by FreeCom. As shown by the small sample batch file, the behavior of the current version of FreeCom is different from the behavior of command.com and 4dos.com. I have made a clean installation of FreeDOS 1.1 and I am not aware of having break something during installation. But anyway this is not a problem to me anymore because I have replaced FreeCom with 4dos. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. The only one I'm aware of is the read from NUL bug, which Jeremy already fixed in his unofficial Git snapshots. (Yes, for some reason, DJGPP insists on reading from that, heh.) http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2014/03/28/16:38:35 To clarify the issue. I was playing with the idea to release an .iso image containing a full DJGPP installation for 2.03, 2.04 and with libc.a build from DJGPP's CVS repository. The goal here was to have a reference DJGPP installation so that users that may have difficulties building some projects can try this installation. For me the question arised if this image should be bootable or not. If bootable then the only possible OS that would make sense would be FreeDOS. It was clear to me that if the image would be bootable then certainly some users would ask if it would be possible to compile their gnu projects on FreeDOS. Most of the user nowadays have Win8 instead as WinXP as default OS. So it becomes necessary to test if FreeDOS can be used as OS to configure and compile projects of such complexity. Until now I have used MSDOS 6.22 instead of FreeDOS. If I get it working on MSDOS I try FreeDOS. If it does not work with MSDOS I assume that it also does not work with FreeDOS. Until now I was not able to compile any DJGPP port of GNU projects except for ed-110s.zip. The reason for this is that it is probably the last GNU project that does not use the AUTOCONF/AUTOMAKE generated configure scripts. I was not able to configure any of the contemporaneous GNU programs like m4, bison or grep. Trying to configure and compile GNU programs on FreeDOS have revealed at least the following issues: 1) The read from NUL bug. Yes this is a bug due to 2 reasons. a) If a command like this: program.exe NUL is not forbidden it is allowed. AFAIK, microsoft has not published any documentation that states that reading from NUL is not defined. b) If it works with microsoft dos kernels it should work with FreeDOS kernels too or they are not really full compatible. Of course, how compatible the FreeDOS kernel shall be is a design decision that must be taken by the maintainers. Last but not least it is not DJGPP that insists on reading from NUL. DJGPP is only used to run script/programs developed for posix. Please note I am very happy to know that this issue has already been fixed but as a newbie to FreeDOS is it of no practical use to me to know that the fix is in some local GIT repository. As a newbie or average FreeDOS user I will certainly not install one compiler more (aka OW) and try to become familiar with a compiler I have never used in my life only to compile a fixed kernel. I would expect a pointer to a zip file that contains a fixed kernel so I can replace the broken one. 2) Long file name support. LFN support is an absolute must-have for contemporaneous software development. The times of 8+3 file name restrictions are long gone. Of course, I am aware of the existence of DOSLFN-like TSRs and I have installed DOSLFN 0.41c on my MSDOS 6.22 machine and also on the FreeDOS installation. Neither less this is of no practical use except for the fact the TSR creates LFNs. IMHO, if the LFN support would be integrated into the kernel it would become much faster and thus
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi Juan, It is still not fully clear to me how different DOS differs regarding the arguments passed to batch situation... Even if 4DOS solves it, what exactly is the difference in style? The only one I'm aware of is the read from NUL bug, which Jeremy already fixed in his unofficial Git snapshots. (Yes, for some reason, DJGPP insists on reading from that, heh.) http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2014/03/28/16:38:35 Interesting. Until now I was not able to compile any DJGPP port of GNU projects except for ed-110s.zip. The reason for this is that it is probably the last GNU project that does not use the AUTOCONF/AUTOMAKE generated configure scripts. It is quite normal that you have to adjust things when making a port: It is rare that a Linux tool source code simply compiles in DJGPP to make a working DOS port... I was not able to configure any of the contemporaneous GNU programs like m4, bison or grep. If you cannot find a sufficiently up to date autoconf or automake, you can start by porting one or, probably often easier, manually adapt makefiles instead of autoadapting. 1) The read from NUL bug. Yes this is a bug due to 2 reasons. a) If a command like this: program.exe NUL is not forbidden it is allowed. AFAIK, microsoft has not published any documentation that states that reading from NUL is not defined. b) If it works with microsoft dos kernels it should work with FreeDOS So what is the desired behaviour of program.exe NUL and what is the current FreeDOS behaviour? I remember that the topic had some ambiguity but I think as long as it is not breaking something else, mimicking Microsoft sounds better. Last but not least it is not DJGPP that insists on reading from NUL. DJGPP is only used to run script/programs developed for posix. Please note I am very happy to know that this issue has already been fixed but as a newbie to FreeDOS is it of no practical use to me to know that the fix is in some local GIT repository. As a newbie or average FreeDOS user I assume Jeremy has some daily build style pre-compiled kernels and command.com that you can download somewhere? 2) Long file name support. LFN support is an absolute must-have for contemporaneous software development. The times of 8+3 file name restrictions are long gone. In any case, many GNU source codes use long file names to name the source files, so LFN is a very good thing to have. Of course, I am aware of the existence of DOSLFN-like TSRs and I have installed DOSLFN 0.41c on my MSDOS 6.22 machine and also on the FreeDOS installation. Neither less this is of no practical use except for the fact the TSR creates LFNs. IMHO, if the LFN support would be integrated into the kernel it would become much faster and thus of real practical use. Not really: Many of the tricks used by Microsoft to make LFN fast, such as keeping most of the data in RAM while Windows is running, or specific algorithms, are patented, which probably prevented the DOSLFN authors to use those. For the checks I am using my Thinkpad T60 with MSDOS 6.22 installed on a 2G partition formatted with FAT. On another partition WinXP SP3 is installed (NTFS). I have unzipped on both operating systems the DJGPP port of binutils (aka bnu224sr2.zip). On WinXP it tooks 2:22 minutes and on MSDOS it tooks 52:30 minutes. I think FreeDOS users (having modern hardware) often use the trick to compile in a RAMDISK or in a DOSEMU window in Linux, to have much faster filesystem access. Also, it is not necessary to load extra drivers for LFN in DOSEMU as far as I remember, as it makes Linux directories show up in DOS as magic network drives with long file names. An idea: Have you checked if LFNDOS is faster than DOSLFN? On MSDOS I was not able neither to configure nor to compile the binutils port. Unfortunately, GNU software now often has a focus on Linux, so people neglegt maintaining their ifdefs for DOS, if they had them at all in the first place. Even autoconf/automake itself obviously has this issue. It was clear to all DJGPP developers in those days when Win2K and WinXP rised that DOS was dead and that if DJGPP should survive the primary target had to be NTVDM and no longer pure DOS. Not really - to compile for Windows, MinGW / Cygwin are more obvious choices. So while for writing the DJGPP compiler, it was convenient to use Windows, DJGPP itself has the clear aim to produce programs that you can run in DOS, quite well :-) I am aware that introducing LFN support into the kernel may break backward compatibility with MSDOS. But in that case the backward compatibility has already been broken long time ago by the introduction of FAT32 support. Not necessarily. Also, you can compile FreeDOS without FAT32, which also makes the kernel a few kilobytes
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On Sun, Jul 20, 2014 at 2:53 PM, Eric Auer e.a...@jpberlin.de wrote: Hi Juan, ... Please note I am very happy to know that this issue has already been fixed but as a newbie to FreeDOS is it of no practical use to me to know that the fix is in some local GIT repository. As a newbie or average FreeDOS user I assume Jeremy has some daily build style pre-compiled kernels and command.com that you can download somewhere? ... Compiled kernels from my git source in both standalone and fdpkg formats including source archive. http://www.fdos.org/kernel/testing/git/ This is a fairly stable location and referenced in my github page ( https://github.com/PerditionC/fdkernel). I have a temporary* build of FreeCom at http://www.fdos.org/kernel/command/FreeCom/test/ * where temporary means will be there until a newer version with a fix is released or I otherwise don't see it as needed or I redo my site Jeremy -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi, On Sat, Jul 19, 2014 at 12:00 AM, Mateusz Viste mate...@viste.fr wrote: I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. sed can use other delimiters, if slash is too prohibitive. Sometimes that makes things easier to read and write. Just for silly example (tested under Cygwin): echo $PATH | sed -e '/.*\(\/cygdrive\/c\/rugxulo\/watcom19\/BINNT\).*/s//\1/' ... vs. ... echo $PATH | sed -e '\,.*\(/cygdrive/c/rugxulo/watcom19/BINNT\).*,s,,\1,' Oops. Or did you mean that this bug in FreeCOM might break sed invocations? I doubt it, the double quotes after -e probably protect it from munging. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. The only one I'm aware of is the read from NUL bug, which Jeremy already fixed in his unofficial Git snapshots. (Yes, for some reason, DJGPP insists on reading from that, heh.) http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2014/03/28/16:38:35 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 00:37, schrieb Ralf Quint: On 7/18/2014 3:09 PM, Juan Manuel Guerrero wrote: This is not really disappointing. I was only testing for the possibility to recommend the FreeDOS 1.1 distribution as an alternative to WinXP and/or Win98SE to build DJGPP ports but this seems not really be possible due to different issues and limitations. Regards, Juan M. Guerrero DOS internally should work with both back and forward slashes. Yes, I am aware of this. Any DOS command shell, including MS-DOS 6.22 should not except the forward slashes even in a batch file as you claim, unless the switch char has been deliberately been changed to something else via INT21H, function 37h... I have installed FreeDOS 1.1 9 or 10 months ago. I have played with it some days and not used it again until yesterday. I have certainly not recompiled any components of the distribution. I have also not installed any other program that should change the switch char. No other programs have been installed except those installed by the distribution proper. All this means that I am not aware of having deliberately changed the switch char. May be it is worth to inspect the FreeCom sources to check what switch char has been selected and what does change it if at all. Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 07:35, schrieb Steve Nickolas: On Sat, 19 Jul 2014, Mateusz Viste wrote: Hi all, I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. command.com should not be splitting the strings at all, but should send the parameters in the raw, terminated (iirc) by a newline. It is for the libc to parse them; if otherwise, that is a serious flaw. There *is* the option of 4DOS. Thanks to pointing me to 4DOS. It was the shell I used everyday in the 80s when I worked on DOS. I had completely forgotten about it but it is nice to see that it is still available. It solves the problem. Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On Fri, Jul 18, 2014 at 3:00 PM, Juan Manuel Guerrero juan.guerr...@gmx.de
wrote:
I do not know if this is the right place to report this FreCom issue and
I do not know if this issue is already well known but I would like to
report it anyway.
Please inspect the following batch file:
@echo off
@echo %0
:loop
@echo %1
shift
if not %1 == goto loop
@echo finished with arguments
command.com on MSDOS 6.22, Win98SE and WinXP and also cmd.exe of WinXP
will produce the following output:
test.bat
./..
../.
if the batch file is started like this:
test.bat ./.. ../.
If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped
with FreeDOS 1.1 and start the batch file in exactly the same way I get
the following output:
test.bat
.
/..
..
/.
As can be seen, FreCom seems to interpret any slash as an option marker
like in /? to get help. All microsoft command.com versions and also
cmd.exe
do interpret the slash as an option marker only if it is preceded by some
kind of blank character. This makes it necessary to quote paths written in
unix-style like:
../foo/bar/.
if they shall be passed as arguments to a batch file to be processed by
FreCom.
Is this behavior a bug or a feature?
Regards,
Juan M. Guerrero
In shell/command.c the following patch should fix the issue (assuming
switchar changed).
@@ -331,8 +331,10 @@
break;
case CMD_SPECIAL_DIR: /* pass '\\' '.' too */
if(*rest == '\\' || *rest == '.' || *rest == ':') break;
+if (!isoptch(*rest) *rest == '/') break;
default:/* pass '/', ignore ',', ';' '=' */
-if(!*rest || *rest == '/') break;
+if(!*rest || isoptch(*rest)) break;
if(isargdelim(*rest)) {
rest = ltrimcl(rest);
break;
I have uploaded a build to http://www.fdos.org/kernel/command/FreeCom/test/
commandx.com is same as command.com but compressed with UPX
Note this is very minimally tested build.
dif file has a few other minor changes [use switchar for help /? -- -?
and start towards help showing proper switchar]
To change the switchar add
?switchar=-
to config.sys (you can remove the prompt ? if you always want the switchar
changed)
Note: you will need to add a shell line using the proper switchar or you
may get errors about path when /P and /E are parsed as paths instead of
options.
I believe this is based on latest SVN sources, (the diff file is from svn
diff) as compiled with Open Watcom.
Jeremy
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi Jeremy,
In shell/command.c the following patch should fix the issue (assuming
switchar changed).
@@ -331,8 +331,10 @@
break;
case CMD_SPECIAL_DIR: /* pass '\\' '.' too */
if(*rest == '\\' || *rest == '.' || *rest == ':') break;
+if (!isoptch(*rest) *rest == '/') break;
default:/* pass '/', ignore ',', ';' '=' */
-if(!*rest || *rest == '/') break;
+if(!*rest || isoptch(*rest)) break;
if(isargdelim(*rest)) {
rest = ltrimcl(rest);
break;
Strange idea, why would / always be a switchar
even if you explititly configure switchar to be
something else? Which Windows versions do that?
And of course: Which software is known to set the
switchar to for example - while at the same time
expecting / to be still simultaneously valid...?
Regards, Eric
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On Sat, Jul 19, 2014 at 3:18 PM, Eric Auer e.a...@jpberlin.de wrote:
Hi Jeremy,
In shell/command.c the following patch should fix the issue (assuming
switchar changed).
@@ -331,8 +331,10 @@
break;
case CMD_SPECIAL_DIR: /* pass '\\' '.' too */
if(*rest == '\\' || *rest == '.' || *rest == ':') break;
+if (!isoptch(*rest) *rest == '/') break;
default:/* pass '/', ignore ',', ';' '=' */
-if(!*rest || *rest == '/') break;
+if(!*rest || isoptch(*rest)) break;
if(isargdelim(*rest)) {
rest = ltrimcl(rest);
break;
Strange idea, why would / always be a switchar
even if you explititly configure switchar to be
something else? Which Windows versions do that?
I'm not sure what you are asking. The default switchar is '/' and so will
be treated as an option specifier instead of directory unless the switchar
is changed.
And of course: Which software is known to set the
switchar to for example - while at the same time
expecting / to be still simultaneously valid...?
Regards, Eric
The first part is so / treated same as \ (but not if it is currently the
switch character, which by default it is).
The second part is so it does not hard code / as the switchar.
Note unless the switchar support is compiled in, then FreeCom hard codes it
to '/'. There may be a few other places in FreeCom that expect / as the
switchar; the only one I know of is the help text.
Jeremy
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
I do not know if this is the right place to report this FreCom issue and I do not know if this issue is already well known but I would like to report it anyway. Please inspect the following batch file: @echo off @echo %0 :loop @echo %1 shift if not %1 == goto loop @echo finished with arguments command.com on MSDOS 6.22, Win98SE and WinXP and also cmd.exe of WinXP will produce the following output: test.bat ./.. ../. if the batch file is started like this: test.bat ./.. ../. If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped with FreeDOS 1.1 and start the batch file in exactly the same way I get the following output: test.bat . /.. .. /. As can be seen, FreCom seems to interpret any slash as an option marker like in /? to get help. All microsoft command.com versions and also cmd.exe do interpret the slash as an option marker only if it is preceded by some kind of blank character. This makes it necessary to quote paths written in unix-style like: ../foo/bar/. if they shall be passed as arguments to a batch file to be processed by FreCom. Is this behavior a bug or a feature? Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi, On Fri, Jul 18, 2014 at 2:00 PM, Juan Manuel Guerrero juan.guerr...@gmx.de wrote: I do not know if this is the right place to report this FreCom issue Dunno, not sure it's actively maintained by anyone anymore. http://www.freedos.org/software/?prog=command http://sourceforge.net/p/freedos/svn/HEAD/tree/freecom/ I do not know if this issue is already well known but I would like to report it anyway. If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped with FreeDOS 1.1 and start the batch file in exactly the same way I get the following output: As can be seen, FreCom seems to interpret any slash as an option marker like in /? to get help. All microsoft command.com versions and also cmd.exe do interpret the slash as an option marker only if it is preceded by some kind of blank character. This makes it necessary to quote paths written in unix-style like: ../foo/bar/. if they shall be passed as arguments to a batch file to be processed by FreCom. Is this behavior a bug or a feature? I definitely reported this same quirk to somebody a few years ago. Obviously it was never fixed. It was probably just an unintentional flaw or too obscure to worry about. I mean, most DOS programs don't use *nix slashes as path separators. I wish I had better news for you like, I made a fix, but it's not really that easy. (Not impossible, just very annoying.) -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 18.07.2014 22:30, schrieb Rugxulo: Hi, On Fri, Jul 18, 2014 at 2:00 PM, Juan Manuel Guerrero juan.guerr...@gmx.de wrote: I do not know if this is the right place to report this FreCom issue Dunno, not sure it's actively maintained by anyone anymore. I feared this. I do not know if this issue is already well known but I would like to report it anyway. If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped with FreeDOS 1.1 and start the batch file in exactly the same way I get the following output: As can be seen, FreCom seems to interpret any slash as an option marker like in /? to get help. All microsoft command.com versions and also cmd.exe do interpret the slash as an option marker only if it is preceded by some kind of blank character. This makes it necessary to quote paths written in unix-style like: ../foo/bar/. if they shall be passed as arguments to a batch file to be processed by FreCom. Is this behavior a bug or a feature? I definitely reported this same quirk to somebody a few years ago. Obviously it was never fixed. It was probably just an unintentional flaw or too obscure to worry about. I mean, most DOS programs don't use *nix slashes as path separators. I wish I had better news for you like, I made a fix, but it's not really that easy. (Not impossible, just very annoying.) This is not really disappointing. I was only testing for the possibility to recommend the FreeDOS 1.1 distribution as an alternative to WinXP and/or Win98SE to build DJGPP ports but this seems not really be possible due to different issues and limitations. Regards, Juan M. Guerrero -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On 7/18/2014 3:09 PM, Juan Manuel Guerrero wrote: This is not really disappointing. I was only testing for the possibility to recommend the FreeDOS 1.1 distribution as an alternative to WinXP and/or Win98SE to build DJGPP ports but this seems not really be possible due to different issues and limitations. Regards, Juan M. Guerrero DOS internally should work with both back and forward slashes. Any DOS command shell, including MS-DOS 6.22 should not except the forward slashes even in a batch file as you claim, unless the switch char has been deliberately been changed to something else via INT21H, function 37h... Ralf --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Hi all, I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. regards, Mateusz On July 19, 2014 12:09:51 AM GMT+02:00, Juan Manuel Guerrero juan.guerr...@gmx.de wrote: Am 18.07.2014 22:30, schrieb Rugxulo: Hi, On Fri, Jul 18, 2014 at 2:00 PM, Juan Manuel Guerrero juan.guerr...@gmx.de wrote: I do not know if this is the right place to report this FreCom issue Dunno, not sure it's actively maintained by anyone anymore. I feared this. I do not know if this issue is already well known but I would like to report it anyway. If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped with FreeDOS 1.1 and start the batch file in exactly the same way I get the following output: As can be seen, FreCom seems to interpret any slash as an option marker like in /? to get help. All microsoft command.com versions and also cmd.exe do interpret the slash as an option marker only if it is preceded by some kind of blank character. This makes it necessary to quote paths written in unix-style like: ../foo/bar/. if they shall be passed as arguments to a batch file to be processed by FreCom. Is this behavior a bug or a feature? I definitely reported this same quirk to somebody a few years ago. Obviously it was never fixed. It was probably just an unintentional flaw or too obscure to worry about. I mean, most DOS programs don't use *nix slashes as path separators. I wish I had better news for you like, I made a fix, but it's not really that easy. (Not impossible, just very annoying.) This is not really disappointing. I was only testing for the possibility to recommend the FreeDOS 1.1 distribution as an alternative to WinXP and/or Win98SE to build DJGPP ports but this seems not really be possible due to different issues and limitations. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
On Sat, 19 Jul 2014, Mateusz Viste wrote: Hi all, I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. command.com should not be splitting the strings at all, but should send the parameters in the raw, terminated (iirc) by a newline. It is for the libc to parse them; if otherwise, that is a serious flaw. There *is* the option of 4DOS. -uso. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
