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 of real practical use. 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. MSDOS with DOSLFN is approximately 25 times slower than WinXP. IIRC Win98SE is even a little bit faster than WinXP. If the handling of LFN on FreeDOS does not become as fast as on WinXP and/or Win98SE, FreeDOS is of no _practical_ use for porting purposes of GNU software to DOS. Please note that I am not claiming that MSDOS/FreeDOS together with DOSLFN is of no use but it is of no _practical_ use for my porting purposes. Compiling on WinXP tooks 07:45 minutes. If compiling on MSDOS with LFN support is also at least a factor of 25 times slower then it would not make to much sense to do it if there is an alternative available like Win98SE or WinXP. A software package like latest DJGPP port of GCC takes approximately 9 hours to compile on WinXP. It becomes clear that from a practical point of view such a package cannot be compiled on FreeDOS using DOSLFN. On MSDOS I was not able neither to configure nor to compile the binutils port. I am still investigation all the reasons and I do not claim that FreeDOS is the reason for the failure. It must be noted that DJGPP 2.04 and all the code stored in the repository has been developed for NTVDM and _not_ for DOS. 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. This design decision may have introduced incompatibilities that are detected now when some one tries to use pure DOS instead of NTVDM. 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. The LFN support could always be disabled by default and enabled explicitly by the user by some setting in config.sys. 3) The "../foo/bar/." batch file option issue when using FreeCom. This issue seem already have been solved either by using 4DOS or with the by Jeremy fixed FreeCom. 4) The AUTOTOOLS generated configure scripts try to execute bash and the script like this: exec /dev/c/djgpp-2.03/bin/sh ../configure --disable-dependency-tracking --disable-nls --enable-install-bfd --enable-install-libiberty --with-mpc=/dev/env/DJDIR --with-mpfr=/dev/env/DJDIR --with-gmp=/dev/env/DJDIR --enable-build-warnings=-Wimplicit,-Wcomment,-Wformat,-Wparentheses,-Wpointer-arith This line fails for DJGPP 2.03 and 2.04. I still have not figured out what is failing here. On Win98SE and WinXP this works flawlessly. As can be seen the shell script to execute have become increasingly complex over the years and DJGPP has been targeted to execute them on Windows versions but not on pure DOS. Although I will continue investigating all these and future issues I have conclude that it will be very unlikely that FreeDOS can be recommended as a substitute for WinXP and/or Win98SE to porting contemporary GNU software to DOS. Using a cross-compiler will be the more efficient approach although debugging will become difficult. Regards, Juan M. Guerrero P.S.: last but not least, due to my limited english skills some sentences may sound harsh but the is no offending intention. ------------------------------------------------------------------------------ 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
