how to use unzip with pipe
Danish
Can anyone please guide me as to how use pipe with unzip. For eg, Iv
got a lot of zip files in a directory. So id like to `ls` them to a
pipe and then unzip it.
$ls *.zip
1.zip
2.zip
Can I do
$ls *.zip | unzip
I tried it, but was not working...Tried googling but didnt find
much..Need it urgently
Thanks
Danish
Hermann Peifer
> Can I do
> $ls *.zip | unzip
>
man xargs
HTH. Hermann
news.t-online.de
ls *.zip | xargs unzip
Danish
Thanks you...xargs did the job
Danish
Stephan 'smg' Grein
Hash: SHA1
Why not just cd "$ZIP_DIR" && unzip *.zip?
Best regards,
- --
Stephan 'smg' Grein, <stephan at stephan minus rockt dot de>
http://stephan-rockt.de
GnuPG-Key-ID: 0xF8C275D4
FingerPrint: 5B6F 134A 189B A24D 342B 0961 8D4B 0230 F8C2 75D4
Geek by nature, Linux by choice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iQIVAwUBROBFIY1LAjD4wnXUAQLqSg/7BJkLc7Lrr8dSKWxUbO4ANekYASRZw/N+
SAtOzD9V8sRwYntH06MGeAMrbByM5ZBTzvpwL0CRjczwwpRd7vtuKHfT+CXSOO20
rSjqllXDyqcJYbGggmCJLIKQsa+mMQGeMEoyc1iPjqNSX8EjSfS0wbHvDf8eR1mg
6OIKv9lsNa7e0darCl7IBkkKzin9QyPwA3NN+hCTwYTAryOos5/mjLQxkDTwxmaO
Ly5VDjh98eIis8hAbWn78Bk+1h/T84m3JNcZISCCCvAXaq5PIZOQeABrqmXSdVso
Ilxk9vzB77uDkvWRybk02IoJSjaVLjoBJEbHA86bGtPF1pPOt5w8kGtMeiIQpuT8
q2jX/bULBhn4zfm3aXoYlWX7Y5N6HyDq5Denky7/oFQDfFFzgAOdkwScHWqzlxzQ
x42zxVsKrnkUjxV7i/2nEVzuL/Fj3asJK/P92fFFfEKVQGmv4lOAJYN++A8aiX5l
UZvfLOUXAPyQz4NS1fI+Al0zTqPuWgaZ1EIM13Fq6CspbgcfdWcFf5pfkMa927q0
voAViV/3a4d49PS//5K6ajARG84bkreRyRV6BN/nxlpfnsOtY4DSs0qaUKVX0RA+
yWSUS9g2gJwslFbMseGjYRduYytR1d2rkPlzmO/6dxC9yerhJW14NWrQ3Op5Okzm
e1yO7kwM+MI=
=Ftmu
-----END PGP SIGNATURE-----
Stephane Chazelas
> Hi,
> Can anyone please guide me as to how use pipe with unzip. For eg, Iv
> got a lot of zip files in a directory. So id like to `ls` them to a
> pipe and then unzip it.
>
> $ls *.zip
>
> 1.zip
> 2.zip
>
> Can I do
> $ls *.zip | unzip
Assuming your shell is zsh:
for f (./*.zip) unzip $f
With Bourne-like shells (including zsh):
for f in ./*.zip; do unzip "$f"; done
--
Stephane
news.t-online.de
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Danish wrote:
>
>>news.t-online.de wrote:
>>
>>>Danish wrote:
>>>
>>>>Hi,
>>>>Can anyone please guide me as to how use pipe with unzip. For eg, Iv
>>>>got a lot of zip files in a directory. So id like to `ls` them to a
>>>>pipe and then unzip it.
>>>>
>>>>$ls *.zip
>>>>
>>>>1.zip
>>>>2.zip
>>>>
>>>>Can I do
>>>>$ls *.zip | unzip
>>>>
>>>>I tried it, but was not working...Tried googling but didnt find
>>>>much..Need it urgently
>>>>
>>>>Thanks
>>>>Danish
>>>>
>>>
>>>Try
>>>ls *.zip | xargs unzip
>>
>>Thanks you...xargs did the job
>>
>>
>>Danish
>>
>
> Why not just cd "$ZIP_DIR" && unzip *.zip?
zip files,00001.zip ... 99999.zip
If you then type unzip *.zip,
the shell will exapnd it to 00001.zip 00002.zip ... 99999.zip.
this would give a coammand line of appx 800000 KB.
for some shells this is to large, and it would say,
command line to large or so.
xargs knows about this limit, e.g 4kb
and distributes the arguments across several
invocations of the command
unzip 00001.zip .... 00050.zip
unzip 00051.zip .... 00100.zip
...
In this paricular case of unzip,
it might be, that unzip knows
about wild cards it self, maybe an
unzip "*.zip"
would do it as well.
Wildcards in "s are not expanded by the shell
and are passed to the program.
news.t-online.de
> Stephan 'smg' Grein wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Danish wrote:
>>
>>> news.t-online.de wrote:
> this would give a coammand line of appx 800000 KB.
I think it is actually the kernel, there
is a way to find out (showconfig or so).
>
>
>
>
>
>
Martijn Lievaart
Won't work, ls commandline might overflow and unzip doesn't work that way.
Try
echo *.zip | xargs -l unzip
Or the simple for loop posted by Stefane.
M4
--
Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering
their time inventing and implementing new, exciting ways for software
to suck. -- Toni Lassila in the Monastry
news.t-online.de
> On Mon, 14 Aug 2006 09:39:03 +0200, news.t-online.de wrote:
>
>
>>Danish wrote:
>>
>>>Hi,
>>>Can anyone please guide me as to how use pipe with unzip. For eg, Iv
>>>got a lot of zip files in a directory. So id like to `ls` them to a
>>>pipe and then unzip it.
>>>
>>>$ls *.zip
>>>
>>>1.zip
>>>2.zip
>>>
>>>Can I do
>>>$ls *.zip | unzip
>>>
>>>I tried it, but was not working...Tried googling but didnt find
>>>much..Need it urgently
>>>
>>>Thanks
>>>Danish
>>>
>>
>>Try
>>ls *.zip | xargs unzip
>
>
> Won't work, ls commandline might overflow and unzip doesn't work that way.
> Try
>
> echo *.zip | xargs -l unzip
>
> Or the simple for loop posted by Stefane.
>
> M4
find . -name "*.zip" -print | xargs unzip
Martijn Lievaart
>>>Try
>>>ls *.zip | xargs unzip
>>
>>
>> Won't work, ls commandline might overflow and unzip doesn't work that way.
>> Try
>>
>> echo *.zip | xargs -l unzip
>>
>> Or the simple for loop posted by Stefane.
>>
>> M4
> Oh yes, then ls already blast the command line buffer.
> find . -name "*.zip" -print | xargs unzip
Won't work.
1) Will also find all zip files in subdirectories, which may or may not be
what was intended.
2) unzip takes as arguments one zipfile and after that the files to
extract. You need the -l to xargs.
Stephane Chazelas
[...]
>> find . -name "*.zip" -print | xargs unzip
>
> Won't work.
>
> 1) Will also find all zip files in subdirectories, which may or may not be
> what was intended.
> 2) unzip takes as arguments one zipfile and after that the files to
> extract. You need the -l to xargs.
-l if for line based.
i.e.
If the input is:
file1 file2
file3
It runs unzip file1 file2, and unzip file3
If you want one file at a time it's:
xargs -n1
But find has to output the file paths in xargs format:
"file1 with spaces" 'file2 with "quotes"'
...
find is not compatible with xargs except if you use the
non-standard -print0/xargs -0.
You probably want:
find . -name '*.zip' -exec unzip {} \;
Which additionaly works better if there's not zip file.
--
Stephane
Martijn Lievaart
> You probably want:
>
> find . -name '*.zip' -exec unzip {} \;
>
> Which additionaly works better if there's not zip file.
Yup, you're right.
Stephan 'smg' Grein
Hash: SHA1
Martijn Lievaart wrote:
> On Tue, 15 Aug 2006 12:05:58 +0000, Stephane Chazelas wrote:
>
>> You probably want:
>>
>> find . -name '*.zip' -exec unzip {} \;
>>
>> Which additionaly works better if there's not zip file.
>
> Yup, you're right.
>
> M4
Maybe you add the -print0 option to be whitespace save.
Therefore: find . -name '*.zip' -print0 -exec unzip {} \;
b.R.,
- --
Stephan 'smg' Grein, <stephan at stephan minus rockt dot de>
GnuPG-Key-ID: 0xF8C275D4
FingerPrint: 5B6F 134A 189B A24D 342B 0961 8D4B 0230 F8C2 75D4
Geek by nature, Linux by choice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iQIVAwUBROHp1o1LAjD4wnXUAQIqohAApDF1r4PYSmx3UJg2KQe79EAh7VwiHo/I
Rp8nJ+Wbr00L8cJcXoG84Lddk1uk8jK4qe1Ma5ldjuoWVuwQDZ5dBR7Gwk2sqXfU
/MpRQ6n516y3UA5TeK2n76hbl/rtCjPZR4qAVBg8y9DPZrhY/w+fsUvIKe/eiuFz
CGUva49WRE3hZxOT5HXyluxqIdv2CEoQgZipjYy8+4OmEPlZ+S26IKpLCogDz2sc
zwn3NKhl/GHo0n3/IoxyJ/aN39dSiO3sj8sYN0zmytDedYQYgd3EDX/Ck8WAFiCB
DwkLMMUT5utj81tRE+ayC6S+fJ8ZskfB/3R2g61EQraPDXo4UaSZfmaS+U8K4OPp
zt/IdsaRFA8Y5UuCA0i5kooAyXy0FhLFJSgY2u63Wvx/JqZ/+9UnsTTMZjjHol+P
V2cNZMRgIC3ryhec/r/Zht4X4ng5Z/fNS3FDCOTYjQbU5TWSKFZagYFV8gtEVNFn
FJ1mIGvAI2pzVoD9I5HlZa8x9BuBGQZFFoivBM6eYJbNrwTlUxqmgX0uQP6y877w
QNbs+ZI5MtpcgxXqwVwmqv7KZmQv+BKOEn2DnL4RxBqHh2E/9Zu3yPJhOaIuG6fa
1Q2vJXQ6gmwu57PN8pm++KnbpFtNOOD+iTcO61tv7a94+VkBTF1IYqcpWOp0iIMK
9lb6i3ySzt8=
=yc1+
-----END PGP SIGNATURE-----
josea...@gmail.com
josea...@gmail.com
josea...@gmail.com
Try this:
for i in `ls *.zip`; do unzip $i; done
Chris F.A. Johnson
>
> Danish wrote:
>> Hi,
>> Can anyone please guide me as to how use pipe with unzip. For eg, Iv
>> got a lot of zip files in a directory. So id like to `ls` them to a
>> pipe and then unzip it.
>>
>> $ls *.zip
>>
>> 1.zip
>> 2.zip
>>
>> Can I do
>> $ls *.zip | unzip
>>
>> I tried it, but was not working...Tried googling but didnt find
>> much..Need it urgently
>
> for i in `ls *.zip`; do unzip $i; done
DON'T try that. Not only is ls unnecessary, but it will break the
script if there are spaces in any of the file names.
for i in *.zip ## the correct way
do
unzip "$i" ## The quotes are needed in case of spaces
done
--
Chris F.A. Johnson, author <http://cfaj.freeshell.org>
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence
Stephane Chazelas
[...]
> for i in *.zip ## the correct way
> do
> unzip "$i" ## The quotes are needed in case of spaces
> done
Even better:
for i in ./*.zip ## the correct way
do
unzip "$i" ## The quotes are needed in case of spaces
done
In case some filenames start with a dash.
or simply, with zsh:
for f (./*.zip) unzip $i
(the quotes are not necessary as zsh fixed that bug/misfeature
of the other shells whereby word splitting (and filename
generation!) is done by default upon variable expansion. And
contrary to with other shells, unzip will not be run if there's
no zip file in the current directory).
Maybe it's worth pointing out that the zip files whose name
starts with a dot will be ommitted, and that all types of files
(including directories and symlinks...) will be considered.
With zsh you can add (D) to the globbing pattern to include the
dotfiles and (.) to only consider regular files:
for f (./*.zip(D.)) unzip $i
Equivalent of:
find . \( -name . -o -prune \) -name '*.zip' -type f \
-exec unzip {} \;
needed for other shells.
(except that zsh will process the list in alphabetic order).
--
Stephane
Martijn Lievaart
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martijn Lievaart wrote:
>> On Tue, 15 Aug 2006 12:05:58 +0000, Stephane Chazelas wrote:
>>
>>> You probably want:
>>>
>>> find . -name '*.zip' -exec unzip {} \;
>>>
>>> Which additionaly works better if there's not zip file.
>>
>> Yup, you're right.
>>
>> M4
> Maybe you add the -print0 option to be whitespace save.
> Therefore: find . -name '*.zip' -print0 -exec unzip {} \;
The -print0 option only affects stdout, not -exec. So either
find . -maxdepth 1 -name '*.zip' -exec unzip {} \;
or if your find and xargs support it
find . -maxdepth 1 -name '*.zip' -print0 | xargs -n1 -0 unzip
M4
Stephan 'smg' Grein
Hash: SHA1
Martijn Lievaart wrote:
> On Tue, 15 Aug 2006 17:35:50 +0200, Stephan 'smg' Grein wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Martijn Lievaart wrote:
>>> On Tue, 15 Aug 2006 12:05:58 +0000, Stephane Chazelas wrote:
>>>
>>>> You probably want:
>>>>
>>>> find . -name '*.zip' -exec unzip {} \;
>>>>
>>>> Which additionaly works better if there's not zip file.
>>> Yup, you're right.
>>>
>>> M4
>> Maybe you add the -print0 option to be whitespace save.
>> Therefore: find . -name '*.zip' -print0 -exec unzip {} \;
>
> The -print0 option only affects stdout, not -exec. So either
>
Ok. I din't know.
> find . -maxdepth 1 -name '*.zip' -exec unzip {} \;
>
> or if your find and xargs support it
>
> find . -maxdepth 1 -name '*.zip' -print0 | xargs -n1 -0 unzip
>
> M4
I think your last version will be my favorite, if I need to use unzip
with pipe. :)
b.r.;
- --
Stephan 'smg' Grein, <stephan at stephan minus rockt dot de>
GnuPG-Key-ID: 0xF8C275D4
FingerPrint: 5B6F 134A 189B A24D 342B 0961 8D4B 0230 F8C2 75D4
Geek by nature, Linux by choice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iQIVAwUBROJGMI1LAjD4wnXUAQJlbxAAmM3v8rW2/EXqwYyT0MMxAZ3bD4Zn4xVM
lYg40ci7k8OvnvRnHLFPX4TXPB7suf8bWyLxJm8iRI1cDPNwZtvoiFzQhZVJMie6
qdlR38aK2UebIyNxTORdjHchg4vVdXk5YifcAhEd6WDxtZoZQyMwb1PG6wYvS2Bd
XmmI+Iqn21kBdLaOtTy1j+5b/9ceEZO1K86ND0SbM5OGES/eUmO9Hauq8J/lvu5G
3Axwlf1Bu9/1NmpcYStfqCPQ4bIAesvPXYOaB6rizqwvKyWvRgzyj65qZ+vbgvV1
3kE6zW8PU+HtGONqhb2AXDDXHq2l30UdMlbgy0u/p9TrrlGF/IkjzW0qQb4xgG9u
Ku3H93HQGl52TtTViN4lfMyxbOHCyzGA0qurJg3w9R6aKxrwmS/jeUR1AmRC0NZ0
M7hhWBLeKrNvn78RjGeD2LYswldUgUqljn2azh6vFnnsbblGeZZwVhKEswQruaZV
N21ivHT+eYNoNBFhHjTg7wNB/5zdy6A5fwdbEzIa1Lz6bEsUOsVBfGEG1I9yFMnI
UVmGxKrp6i61HGWlrM7WnChyXBaue80X0cmJQZuJ4ag7DBsX1znwyHLf7bWJc044
oDC7Vlk/F4HPTTV7nBzwBREiK2VvyciXrf/p8rzYBAVjG2H/MtUeosmntNmfMdw9
E48kAlYwha0=
=qi7d
-----END PGP SIGNATURE-----
Stephane Chazelas
[...]
>
> find . -maxdepth 1 -name '*.zip' -exec unzip {} \;
>
> or if your find and xargs support it
>
> find . -maxdepth 1 -name '*.zip' -print0 | xargs -n1 -0 unzip
While you're at using GNU specific options, you can add the "-r"
option to xargs so that it doesn't run unzip if there's no zip
file.
-maxdepth, -print0, -0 and -r are GNU specific though they can
also be found in the "find/xargs" of some BSDs.
find . \( -name . -o -prune \) -name '*.zip' \
-exec unzip {} \;
does the same and is standard and portable.
--
Stephane
Martijn Lievaart
> -maxdepth, -print0, -0 and -r are GNU specific though they can
> also be found in the "find/xargs" of some BSDs.
I didn't know -maxdepth is GNU specific, I'm a bit out of the bigger iron
these days. Thanks for the info.
>
> find . \( -name . -o -prune \) -name '*.zip' \
> -exec unzip {} \;
>
> does the same and is standard and portable.
Thanks for the correction. But if we're going to make it completely
correct:
find . \( -name . -o -prune \) \( -type f -o -type l \) \
-name '*.zip' -exec unzip {} \;
I suddenly understand why some people find unix user unfriendly.
Stephane CHAZELAS
[...]
>> find . \( -name . -o -prune \) -name '*.zip' \
>> -exec unzip {} \;
>>
>> does the same and is standard and portable.
>
> Thanks for the correction. But if we're going to make it completely
> correct:
>
> find . \( -name . -o -prune \) \( -type f -o -type l \) \
> -name '*.zip' -exec unzip {} \;
>
> I suddenly understand why some people find unix user unfriendly.
Why would you unzip symlinks? They don't all point to regular
files and you may end up unzipping the same file twice.
find . -follow \( -name . -o -prune \) -name '*.zip' \
-type f -exec unzip {} \;
or POSIXly:
find -H . \( -name . -o -prune \) -name '*.zip' \
-type f -exec unzip {} \;
To test whether the files are regular files or symlinks to
regular files.
The zsh equivalent:
for f (./*.zip(D-.)) unzip $f
--
Stéphane
Stephane CHAZELAS
[...]
> find -H . \( -name . -o -prune \) -name '*.zip' \
> -type f -exec unzip {} \;
Sorry, -L instead of -H.
Or you can add a -exec test -f {} \;
The problem with -L or -follow is that it follows symlink also
for walking down the directory tree which you generally don't
want.
GNU find has -xtype to test on the type of the file pointed to
by the symlink.
--
Stéphane
Martijn Lievaart
> 2006-08-17, 07:58(+01), Stephane CHAZELAS:
> [...]
>> find -H . \( -name . -o -prune \) -name '*.zip' \
>> -type f -exec unzip {} \;
>
> Sorry, -L instead of -H.
>
> Or you can add a -exec test -f {} \;
That's a good trick!
> The problem with -L or -follow is that it follows symlink also
> for walking down the directory tree which you generally don't
> want.
>
> GNU find has -xtype to test on the type of the file pointed to
> by the symlink.
OK, thanks!
Ilya Zakharevich
Danish
<me.lin...@gmail.com>], who wrote in article <1155537414.0...@m79g2000cwm.googlegroups.com>:
> Hi,
> Can anyone please guide me as to how use pipe with unzip. For eg, Iv
> got a lot of zip files in a directory. So id like to `ls` them to a
> pipe and then unzip it.
>
> $ls *.zip
>
> 1.zip
> 2.zip
>
> Can I do
> $ls *.zip | unzip
>
> I tried it, but was not working...Tried googling but didnt find
> much..Need it urgently
Out of tens of postings, nobody gave a "correct" one:
unzip "*.zip"
Hope this helps,
Ilya
Danish
Thank you very much
Danish
Stephane Chazelas
[...]
>> Out of tens of postings, nobody gave a "correct" one:
>>
>> unzip "*.zip"
Indeed, there's a bug in unzip that makes it behave the msdos
way even on Unix (where *, ?, [, \ are allowed in filenames).
So the only correct one is
unzip "*.zip"
And if you want to use a for loop or find, you need to escape
the *, ?, \ and [ characters first in filenames:
Something like:
for f in ./*.zip; do
[ -f "$f" ] || continue
[ -L "$f" ] && continue
escaped_f=$(
printf '%s\n' "$f" | sed 's/[][\?*]/\\&/g'
)
unzip "$escaped_f"
done
--
Stephane
Chris Mattern
Dear God, that's ugly. Whoever decided unzip shouldn't
handle a list of filenames but *should* try to do its own
globbing needs to be shot.
Chris Mattern
Ilya Zakharevich
<sys...@gwu.edu>], who wrote in article <12ejf8n...@corp.supernews.com>:
> >>>Out of tens of postings, nobody gave a "correct" one:
> >>> unzip "*.zip"
> Dear God, that's ugly. Whoever decided unzip shouldn't
> handle a list of filenames but *should* try to do its own
> globbing needs to be shot.
Opionions differ. IMO, whoever got this (broken) idea that it is the
shell who globs (and not CRTL of the called application) should be
treated unmercifully.
Only the arguments which are meaningful to be globbed should be
globbed, and only the application knows its syntax to support this.
Otherwise you get this "just do not have a file named `-rf'" logic.
Of course, this flaw can't be easily fixed in current Unix shells
(well, interaction with `complete' database can somewhat help here).
But whoever (?) wants to design a better shell (on a system with
not-yet finished CRTL ;-), could revisit this problem.
But I already expressed this opinion many times...
Hope this helps,
Ilya
Daniel Rock
> Opionions differ. IMO, whoever got this (broken) idea that it is the
> shell who globs (and not CRTL of the called application) should be
> treated unmercifully.
Why should the wheel be reinvented for each and every application what
can be done in a consistent manner by a single instance (the shell)?
--
Daniel
Ilya Zakharevich
<v20...@deadcafe.de>], who wrote in article <eeofqi$26a7$2...@server.rock.net>:
> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> > Opionions differ. IMO, whoever got this (broken) idea that it is the
> > shell who globs (and not CRTL of the called application) should be
> > treated unmercifully.
>
> Why should the wheel be reinvented for each and every application
Not in applications; as I said, the default, "legacy-compatible",
globbing would be done in CRTL. The applications should be able to
override this.
> what can be done in a consistent manner by a single instance (the
> shell)?
By definition, shell can't do any reasonable globbing; otherwise you
get the "just do not have a file named -rf" syndrom. Only the
application knows which arguments can have a meaning of a
file-pattern, so may be globbed.
Hope this helps,
Ilya
Daniel Rock
> Only the application knows which arguments can have a meaning of a
> file-pattern, so may be globbed.
... and that in a wonderful inconsistent way:
C:\> cd Prog*
C:\Programme>
Note: Globbing is technically wrong here since "cd" only expects a single
directory name as an argument.
[In a directory with lots of .TXT-Files]
C> notepad *.txt
[a dialog pops up
The syntax for file name, directory name or volume name is wrong
(manually translated)]
Note: Globbing makes sense here because I might want to edit multiple files
at the same time.
It's better let this shell doing this. And your famous "-rf" filename:
-- is your fried. A much better work-around than begging for each
application programmer implementing globbing consistent.
> Hope this helps,
Hope this helps,
--
Daniel
Spiros Bousbouras
> [A complimentary Cc of this posting was sent to
> Daniel Rock
> <v20...@deadcafe.de>], who wrote in article <eeofqi$26a7$2...@server.rock.net>:
> > Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> > > Opionions differ. IMO, whoever got this (broken) idea that it is the
> > > shell who globs (and not CRTL of the called application) should be
> > > treated unmercifully.
> >
> > Why should the wheel be reinvented for each and every application
>
> Not in applications; as I said, the default, "legacy-compatible",
> globbing would be done in CRTL. The applications should be able to
> override this.
What's CRTL ?
> > what can be done in a consistent manner by a single instance (the
> > shell)?
>
> By definition, shell can't do any reasonable globbing; otherwise you
> get the "just do not have a file named -rf" syndrom. Only the
> application knows which arguments can have a meaning of a
> file-pattern, so may be globbed.
Yet , in the vast majority of cases the globbing the shell does
works fine. The only time globbing produced unexpected results
for me was years ago when I accidentally ended up with a file whose
name started with - in my home directory.
But I can't evaluate the alternative you're proposing because
I don't know what CRTL is.
Kenny McCormack
Spiros Bousbouras <spi...@gmail.com> wrote:
>Ilya Zakharevich wrote:
>
>> [A complimentary Cc of this posting was sent to
>> Daniel Rock
>> <v20...@deadcafe.de>], who wrote in article <eeofqi$26a7$2...@server.rock.net>:
>> > Ilya Zakharevich <nospam...@ilyaz.org> wrote:
>> > > Opionions differ. IMO, whoever got this (broken) idea that it is the
>> > > shell who globs (and not CRTL of the called application) should be
>> > > treated unmercifully.
>> >
>> > Why should the wheel be reinvented for each and every application
>>
>> Not in applications; as I said, the default, "legacy-compatible",
>> globbing would be done in CRTL. The applications should be able to
>> override this.
>
>What's CRTL ?
C Run Time Library
The idea is that it could be consistent at the application level (all
applications uses the same startup code and run time libraries would get
the same globbing behavior).
Anyway, my 2 cents worth is that the Unix/shell way is the right way,
but that there should be a way for the application to get at the raw,
unparsed command line if it needs/wants to. Windows (sort of) gives you
this via the COMMANDLINE environment variable.
Ilya Zakharevich
Daniel Rock
> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> > Only the application knows which arguments can have a meaning of a
> > file-pattern, so may be globbed.
>
> ... and that in a wonderful inconsistent way:
>
> C:\> cd Prog*
> C:\Programme>
>
> Note: Globbing is technically wrong here since "cd" only expects a single
> directory name as an argument.
>
> [In a directory with lots of .TXT-Files]
>
> C> notepad *.txt
> [a dialog pops up
> The syntax for file name, directory name or volume name is wrong
> (manually translated)]
>
> Note: Globbing makes sense here because I might want to edit multiple files
> at the same time.
I have no idea examples of what are your examples. What are you
trying to proof? That implementation of globbing may be goofy?
Implementation of anything can be goofy...
> It's better let this shell doing this.
My point is that it is not.
> And your famous "-rf" filename:
> -- is your fried.
Do not think so. If you think so, try creating an alias which would
insert -- automatically unless I want to put options.
> A much better work-around than begging for each
> application programmer implementing globbing consistent.
Apparently, you did not read what I wrote. There are only two places
to implement globbing: in CRTL startup code - for backward
compatibility, and in getopt().
Hope this helps,
Ilya
Daniel Rock
> [A complimentary Cc of this posting was sent to
> Daniel Rock <v20...@deadcafe.de>,
Don't! Either post or eMail but but both. BTW my eMail addresses are only
valid for two weeks. So better hurry next time. And please cut down your
entry novel to a single line.
> who wrote in article <ehcuod$pe2$1...@server.rock.net>:
>> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> I have no idea examples of what are your examples. What are you
> trying to proof? That implementation of globbing may be goofy?
Yes, and that's why it should be done in one central place: Then the
behaviour is always consistent.
> Do not think so. If you think so, try creating an alias which would
> insert -- automatically unless I want to put options.
So don't create an alias.
> Apparently, you did not read what I wrote. There are only two places
> to implement globbing: in CRTL startup code - for backward
> compatibility, and in getopt().
No, leave it to the shell, where it belongs. If you don't want globbing
use quotes.
You then know that your command line arguments are always subject to globbing
and don't have to test if and how your application does it.
> Hope this helps,
No,
Daniel
P.S. Why do you post an answer always a month after the previous one? Do you
want to have the last word - hoping that I have already forgotten this
thread?
Bruce Barnett
> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
>> [A complimentary Cc of this posting was sent to
>> Daniel Rock <v20...@deadcafe.de>,
>
> Don't! Either post or eMail but but both. BTW my eMail addresses are only
> valid for two weeks.
Ah. I bet I can get the next address. 42 of 52.
(I use a timestamp in my e-mail as well.)
--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.
Ilya Zakharevich
Daniel Rock
<v20...@deadcafe.de>], who wrote in article <ejc1cv$1ugo$1...@deadcafe.de>:
> > I have no idea examples of what are your examples. What are you
> > trying to proof? That implementation of globbing may be goofy?
>
> Yes, and that's why it should be done in one central place: Then the
> behaviour is always consistent.
If you like consistency so much, just make argc to be always 1. This
is also a consistent behaviour.
Consistency is not the ONLY desired target.
> > Do not think so. If you think so, try creating an alias which would
> > insert -- automatically unless I want to put options.
>
> So don't create an alias.
So one is back to "just do not have file named -rf".
> No, leave it to the shell, where it belongs.
Well, the whole idea is that it does not belong there (except for
histerical raisins).
Hope this helps,
Ilya
Daniel Rock
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Daniel Rock
> <v20...@deadcafe.de>], who wrote in article <ejc1cv$1ugo$1...@deadcafe.de>:
One line should still be sufficient.
> If you like consistency so much, just make argc to be always 1. This
> is also a consistent behaviour.
What are you trying to say?
> Consistency is not the ONLY desired target.
But inconsistency is undesired most of the time.
> So one is back to "just do not have file named -rf".
No: Simply use your brain. If you don't trust the directories you are in
first take a quick look.
> Well, the whole idea is that it does not belong there (except for
> histerical raisins).
From posts of other people in this thread your opinion is a minory here.
Ilya Zakharevich
Daniel Rock
> > So one is back to "just do not have file named -rf".
>
> No: Simply use your brain. If you don't trust the directories you are in
> first take a quick look.
Year, right. This is just like saying that `ls *.txt` is as good as
*.txt: just quickly look and check whether there are files funny chars
in the names...
> > Well, the whole idea is that it does not belong there (except for
> > histerical raisins).
> From posts of other people in this thread your opinion is a minory here.
Now I wonder why this won't scare me...
Hope this helps,
Ilya
Daniel Rock
posting a response]
I'm tired of you. Good bye.
--
Daniel