GnuWin

Re: [GnuWin32-Users] ls.exe */* From: Peter <one2001boy@ya...> - 2009-06-26 06:20 > > Hello, > > > > ls.exe from mingw binutils-2.19.1-mingw32-bin.tar.gz > works > > for "ls.exe */*" from cmd.exe > > > > not sure if ls.exe from gnuwin32 can get it work out? > > > First, this is established MS-Windows behavior of > command-line utilities. > For example, dir ** does not work either (although it does > have the /s > option for searching recursively). If you need or want unix > or posix > behavior on MS-Windows, use Cygwin. Cygwin doesn't take the path C:/my/directory. it requires to install lots of stuff. what I want is to be able to run grep abc */* from ms-dos shell. grep.exe or ls.exe etc from mingw and djgpp (though it is not very stable for the binary from mingw if running from msdos shell.) It is nice to know that it works for those binaries without cygwin. >Secondly, changing this > would require > adding new code for command-line expansion, which is now > done by the > msvrt-library. So, on the whole, I think it is best to > leave this as it is > now. so you think grep.exe from mingw used msvrt-library to compile? Kees, Thanks for your help Peter

Re: [GnuWin32-Users] ls.exe */* From: Keith MARSHALL <keith.marshall@to...> - 2009-06-26 13:04 > grep.exe or ls.exe etc from mingw and djgpp (though it is not very > stable for the binary from mingw if running from msdos shell.) MS-DOS shell == 16-bit, single user, single tasking system; last ever version published (in 1994), IIRC, was MS-DOS-6.22. If you are really using an MS-DOS shell, you cannot run *any* program from MinGW, because they all require MS-Win32. If, OTOH, what you really mean is a Win32 cmd shell... > It is nice to know that it works for those binaries without cygwin. Ah, but the "MinGW" binaries to which you refer are actually *MSYS* binaries, and MSYS is a light-weight derivative of an early version of Cygwin, so in reality you *are* using Cygwin, although you may not have realised it. You should also be aware that MSYS binaries are *not* intended to be invoked from the cmd.exe shell. They should be used from the Bourne shell, which MSYS itself provides. If you take a fish out of water, can it still swim? While you may achieve some limited success when misusing MSYS tools in this unsupported manner, please don't complain that they don't work reliably; it is your expectations, and method of use, which are at fault. > so you think grep.exe from mingw used msvrt-library to compile? No, it does not. Nor does the ls.exe you also mentioned. As MSYS programs, they are linked against msys-1.0.dll, (which is a derivative of an old Cygwin implementation of newlib), instead of MSVCRT. As a consequence, they inherit Cygwin's command line parsing capabilities, which deliver the full gamut of POSIX pattern matches; MS-Windows' standard pattern matching capabilities, (as available to most native MS-Windows programs, such as the GnuWin32 suite, and including those compiled by MinGW -- MSYS programs are *not* built using this), are rather mediocre in comparison. -- Regards, Keith.

Re: [GnuWin32-Users] ls.exe */* From: Peter <one2001boy@ya...> - 2009-06-29 06:32 --- On Fri, 6/26/09, Keith MARSHALL <keith.marshall@...> wrote: > From: Keith MARSHALL <keith.marshall@...> > Subject: Re: [GnuWin32-Users] ls.exe */* > To: gnuwin32-users@... > Date: Friday, June 26, 2009, 6:03 AM > > > > > > grep.exe or ls.exe etc from  mingw and djgpp > (though it is not very > > stable for the binary from mingw if running from msdos > shell.) > > MS-DOS shell == 16-bit, single user, single tasking system; > last ever > version published (in 1994), IIRC, was MS-DOS-6.22.  > If you are really > using an MS-DOS shell, you cannot run *any* program from > MinGW, because > they all require MS-Win32.  If, OTOH, what you really > mean is a Win32 > cmd shell... I mean win32 cmd shell. > > > It is nice to know that it works for those binaries > without cygwin. > > Ah, but the "MinGW" binaries to which you refer are > actually *MSYS* > binaries, and MSYS is a light-weight derivative of an early > version of > Cygwin, so in reality you *are* using Cygwin, although you > may not > have realised it. > > You should also be aware that MSYS binaries are *not* > intended to be > invoked from the cmd.exe shell.  They should be used > from the Bourne > shell, which MSYS itself provides.  If you take a fish > out of water, > can it still swim?  While you may achieve some limited > success when > misusing MSYS tools in this unsupported manner, please > don't complain > that they don't work reliably; it is your expectations, and > method of > use, which are at fault. Thanks for your information. > > > so you think grep.exe from mingw used msvrt-library to > compile? > > No, it does not.  Nor does the ls.exe you also > mentioned.  As MSYS > programs, they are linked against msys-1.0.dll, (which is a > derivative > of an old Cygwin implementation of newlib), instead of > MSVCRT.  As a > consequence, they inherit Cygwin's command line parsing > capabilities, > which deliver the full gamut of POSIX pattern matches; > MS-Windows' > standard pattern matching capabilities, (as available to > most native > MS-Windows programs, such as the GnuWin32 suite, and > including those > compiled by MinGW -- MSYS programs are *not* built using > this), are > rather mediocre in comparison. > looks that I have to give up the dream using */* from win32 shell. It might not a big deal if converting to bash first. Thanks. Peter > -- > > Regards, > Keith. > ------------------------------------------------------------------------------ > _______________________________________________ > GnuWin32-Users mailing list > GnuWin32-Users@... > https://lists.sourceforge.net/lists/listinfo/gnuwin32-users >

Re: [GnuWin32-Users] ls.exe */* From: Keith MARSHALL <keith.marshall@to...> - 2009-06-08 09:46 > ls.exe from mingw binutils-2.19.1-mingw32-bin.tar.gz works > for "ls.exe */*" from cmd.exe Huh? There is no ls.exe within that package! ls is provided by the coreutils; it has nothing to do with the binutils. The only version of the coreutils provided by the MinGW Project is that specifically for use with the MSYS shell; you cannot reliably use it in cmd.exe Besides, your statement above is a complete contradiction of your own recent post to the MinGW-users list: http://thread.gmane.org/gmane.comp.gnu.mingw.user/29898 -- Regards, Keith.

Re: [GnuWin32-Users] ls.exe */* From: Kees Zeelenberg <kzlg@us...> - 2009-06-25 08:17 -------------------------------------------------- Van: "Peter" Datum: zondag 7 juni 2009 23:48 Aan: Onderwerp: [GnuWin32-Users] ls.exe */* > > Hello, > > ls.exe from mingw binutils-2.19.1-mingw32-bin.tar.gz works > for "ls.exe */*" from cmd.exe > > not sure if ls.exe from gnuwin32 can get it work out? > First, this is established MS-Windows behavior of command-line utilities. For example, dir ** does not work either (although it does have the /s option for searching recursively). If you need or want unix or posix behavior on MS-Windows, use Cygwin. Secondly, changing this would require adding new code for command-line expansion, which is now done by the msvrt-library. So, on the whole, I think it is best to leave this as it is now. Kees Zeelenberg

[GnuWin32-Users] [gnuwin32 - Help] RE: untar to specified folder From: SourceForge.net <noreply@so...> - 2009-06-05 14:10 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7428576 By: keithmarshall If I understand you correctly, you have an archive file in some directory, (you called it "dir_2"), and you want to extract it into another directory, (which you called "dir_3")? Right. tar will, by default, extract into your current working directory, reinstating the hierarchy specified within the archive itself, relative to current directory as prefix. Thus, provided you didn't make the grave error of creating the archive with absolute path names: $ cd d:pathtodir_3 $ tar xvf d:pathtodir_2archive.tar should achieve what you want. (If you *did* create the archive, specifying *absolute* path names for the archived files, then I fear tar will always extract back to the same absolute paths; the moral is: *never* specify absolute path names for the files you add to a tar archive, *always* use a relative path). In an earlier post, you said you did: $ cd dir_2 $ tar xvf archive.tar -C dir_3 (exploiting the GNU tar -C extension feature), and it didn't work. I've never seen that fail, (but then, I use the MSYS implementation of GNU tar, rather than GnuWin32's). When you invoked that command, did your "dir_3" already exist as a subdirectory of "dir_2"? (Hint: tar will try to cd to the directory specified with -C; if it doesn't exist, that must fail; tar will not call mkdir for you). ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807

[GnuWin32-Users] [gnuwin32 - Help] RE: Folders with spaces at end From: SourceForge.net <noreply@so...> - 2009-06-04 09:51 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7426465 By: keithmarshall For a URL such as "http://www.server.com/dirname /some.zip" > wget with options -x -nH cannot download the file some.zip > because it cannot create the "dirname " folder. Hmm. This doesn't answer your question, but one might wonder "why not"? The _mkdir() function in Microsoft's runtime library is perfectly capable of creating directories named with trailing spaces, as indicated in this bug report: https://sourceforge.net/tracker/?func=detail&aid=1959460&group_id=2435&atid=1024 35 ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807

[GnuWin32-Users] [gnuwin32 - Help] RE: Folders with spaces at end From: SourceForge.net <noreply@so...> - 2009-06-04 10:09 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7426484 By: emodric Sorry, you're right. wget CAN create the folder, but it cannot write to it once created, hence, the file cannot be saved. So, my question remains, is it possible to make a patch that creates the folder without trailing space and writes to that folder, instead of creating folder with space which is then unusable? Thanks! ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807

[GnuWin32-Users] [gnuwin32 - Help] RE: Folders with spaces at end From: SourceForge.net <noreply@so...> - 2009-06-05 08:34 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7428138 By: gnuwin32 Yes, mkdir can create a folder with a space at the end of its name, but only when you end the name with a slash. And other folder accessing functions also need this slash at the end of the folder name. So everywhere in the wget source where a folder name is used, one would have to add a slash. The alternative is to delete any trailing spaces before calling mkdir. The latter would be the simplest, because it will probably occur only once or perhaps a few times. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807

[GnuWin32-Users] [gnuwin32 - Help] RE: Folders with spaces at end From: SourceForge.net <noreply@so...> - 2009-06-05 08:54 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7428163 By: keithmarshall > Yes, mkdir can create a folder with a space at the end of its name, > but only when you end the name with a slash... Thanks for this, Kees. That information would likely be relevant to the MSYS bug report too. Would you care to add an appropriate comment, (so you get the attribution), or shall I do so on your behalf? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807

[GnuWin32-Users] [gnuwin32 - Help] RE: Folders with spaces at end From: SourceForge.net <noreply@so...> - 2009-06-05 09:18 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7428198 By: kzlg Done. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807

[GnuWin32-Users] [gnuwin32 - Help] RE: Folders with spaces at end From: SourceForge.net <noreply@so...> - 2009-06-05 10:08 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7428253 By: keithmarshall Thanks, Kees. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=74807