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 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
