find - manipulation
sledge
I am trying to copy all files with the same extension say *.jsp from
the source tree.
I have
fine . -name "*.jsp" -print
How do I get the script to copy the discovered file to a temp
directory.
Thanks
Sledge
pk
find . -name '*.jsp' -exec cp {} /dest/dir \;
if you're using GNU cp you can make it somewhat more efficient by doing
find . -name '*.jsp' -exec cp -t /dest/dir {} +
Sidney Lambe
I can't imagine why he has to do it all with find.
Why not simply:
find ....
cp ...
Sid
Seebs
> I can't imagine why he has to do it all with find.
> Why not simply:
>
> find ....
> cp ...
Well, what do you pass as the arguments to cp? In particular, what do you
do if the find yields files with spaces or newlines in their names, etc.?
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Sven Mascheck
> if you're using GNU cp you can make it somewhat more efficient by doing
>
> find . -name '*.jsp' -exec cp -t /dest/dir {} +
s/GNU cp/any cp/
find ... -exec sh -c 'cp "$@" /dest/dir' find-sh +
Sidney Lambe
> On 2009-11-05, Sidney Lambe <sidne...@nospam.invalid> wrote:
>
>> I can't imagine why he has to do it all with find. Why not
>> simply:
>>
>> find ...
>> cp ...
>
> Well, what do you pass as the arguments to cp?
You could do
cp $(find ...) /dest/dir
> In particular,
> what do you do if the find yields files with spaces or newlines
> in their names, etc.?
I don't have any files with names like that. I don't allow them
on my box. That's Windows garbage. So I can't answer your question.
Can find deal with files like that?
Sid
pk
Oh right, brilliant. Thank you.
Seebs
> You could do
>
> cp $(find ...) /dest/dir
Doesn't work if the output contains any spaces or newlines, or if
there's too many files.
> I don't have any files with names like that. I don't allow them
> on my box. That's Windows garbage. So I can't answer your question.
One of my primary Unix boxes is a Mac.
Which, *out of the box*, has many files with spaces in their names (though
none with newlines).
My BSD boxes often have at least a few filenames containing spaces for
one reason or another. I'm not particularly happy about it, but the spec
says it's okay, so I guess I'm stuck with it. (I do, I might add, wish
that they'd banned newlines in file names completely, but oh well.)
> Can find deal with files like that?
Quite nicely.
Normally, you can use xargs to bundle commmands, but that won't work easily
in this case, because xargs likes to append arguments after the command
given (I don't remember off the top of my head whether the -J option is
portable, and the idiot who wrote my shell book doesn't seem to have
covered it).
Newlines break xargs by default, although many modern find and xargs can
use null bytes instead of newlines; find ... -print0 | xargs -0. Not
totally portable yet.
The -exec option, of course, handles completely arbitrary file names, and
with modern find (not cp, by the way; it's a find feature) you can use +
rather than ; to request that it pass as many arguments as it can per pass.
(If you do use ;, don't forget to escape it so it's not a shell metacharacter
anymore).
If you want justified confidence that it'll work no matter what, you use:
-exec cp {} destdir \;
The other options are either error-prone or unportable.
Seebs
Yes. But not necessarily any find. (As Sven recently pointed out to me,
though, this one is surprisingly broadly available -- I'm writing this on
a box too old to have it, but most systems do now.)
pk
>> find ... -exec sh -c 'cp "$@" /dest/dir' find-sh +
>
> Oh right, brilliant. Thank you.
Well, ITYM
find ... -exec sh -c 'cp "$@" /dest/dir' find-sh {} +
anyway. Still brilliant.
Sven Mascheck
> (I do, I might add, wish that they'd banned newlines in file names
> completely, but oh well.)
I wonder about the consequences of the idea, if the null byte had
been added as alternative filename delimiter to the whole toolchest
in the early days (that is, optionally substituting the newline).
> (I don't remember off the top of my head whether the -J option is
> portable,
I suspect the hotspot is near FreeBSD 4.4 and MacOSX inherited from it?
...and so we rather should forgive him this time,
> It looks like and the idiot who wrote my shell book doesn't seem to have
> covered it).
> [...] although many modern find and xargs can use null bytes instead
> of newlines; [...] find ... -print0 | xargs -0. Not totally portable yet.
A nitpick: probably it will never be portable, because SUS/POSIX moved to
find ... -exec +. (And -print0 never was more portable.)
> The -exec option, of course, handles completely arbitrary file names, and
> with modern find [...] you can use + rather than ; [...]
Honestly, the idea that I might count SVR4 to the modern flavours,
has something heart warming these days. (Call me oldfashioned, there
might come the day, that such is retro.)
Stephane CHAZELAS
> On 2009-11-05, Sidney Lambe <sidne...@nospam.invalid> wrote:
>> You could do
>>
>> cp $(find ...) /dest/dir
>
> Doesn't work if the output contains any spaces or newlines
or "*", or "?" or "[...]"...
--
Stï¿œphane
Seebs
>>> cp $(find ...) /dest/dir
Good point. At which point, you run into an interesting puzzle; you
presumably don't just want it to be quoted (because then it won't be
split into words), but you want some sort of splitting, and yet, no
globbing. I'm a bit sleepy right now, so I can't think of a way to get
splitting without globbing. There may not be one.
pk
> On 2009-11-06, Stephane CHAZELAS <stephane...@yahoo.fr> wrote:
>> 2009-11-05, 22:53(+00), Seebs:
>>> On 2009-11-05, Sidney Lambe <sidne...@nospam.invalid> wrote:
>>>> You could do
>
>>>> cp $(find ...) /dest/dir
>
>>> Doesn't work if the output contains any spaces or newlines
>> [...]
>
>> or "*", or "?" or "[...]"...
>
> Good point. At which point, you run into an interesting puzzle; you
> presumably don't just want it to be quoted (because then it won't be
> split into words), but you want some sort of splitting, and yet, no
> globbing. I'm a bit sleepy right now, so I can't think of a way to get
> splitting without globbing. There may not be one.
set -f
but that still can't do anything against filenames with spaces.
Seebs
> set -f
I'm not sure how portable it is.
> but that still can't do anything against filenames with spaces.
Yup. That's why find's had -exec forever, and why xargs uses newlines.
pk
> On 2009-11-06, pk <p...@pk.invalid> wrote:
>> set -f
>
> I'm not sure how portable it is.
It's specified by POSIX. Of course that does not make it portable across
every imaginable system, but should be a reasonable assurance that it will
be available on most modern shells.
Sidney Lambe
> On 2009-11-05, Sidney Lambe <sidne...@nospam.invalid> wrote:
>
>> You could do
>>
>> cp $(find ...) /dest/dir
>
> Doesn't work if the output contains any spaces or newlines, or
> if there's too many files.
>
>> I don't have any files with names like that. I don't allow
>> them on my box. That's Windows garbage. So I can't answer your
>> question.
>
> One of my primary Unix boxes is a Mac.
It's either Unix or Mac. It can't be both.
> Which, *out of the box*, has many files with spaces in their
> names (though none with newlines).
Unix OSes do not have spaces or newlines in their filenames.
My Slackware Linux certainly does not. It is a Unix clone.
> My BSD boxes often have at least a few filenames containing
> spaces for one reason or another. I'm not particularly happy
> about it, but the spec says it's okay, so I guess I'm stuck
> with it. (I do, I might add, wish that they'd banned newlines
> in file names completely, but oh well.)
"Oh well"? Who is forcing you to use these flawwed OSes?
>
>> Can find deal with files like that?
>
> Quite nicely.
>
> Normally, you can use xargs to bundle commmands, but that
> won't work easily in this case, because xargs likes to append
> arguments after the command given (I don't remember off the top
> of my head whether the -J option is portable, and the idiot who
> wrote my shell book doesn't seem to have covered it).
>
> Newlines break xargs by default, although many modern find and
> xargs can use null bytes instead of newlines; find ... -print0
> | xargs -0. Not totally portable yet.
>
> The -exec option, of course, handles completely arbitrary file
> names, and with modern find (not cp, by the way; it's a find
> feature) you can use + rather than ; to request that it pass
> as many arguments as it can per pass. (If you do use ;, don't
> forget to escape it so it's not a shell metacharacter anymore).
>
> If you want justified confidence that it'll work no matter
> what, you use: -exec cp {} destdir \;
>
> The other options are either error-prone or unportable.
Thanks, but what works for me is to use a decent OS.
Slackware with a basic GUI (no 'desktop environment').
Sid
Seebs
Yeah. I have gotten in the habit of not assuming POSIX behavior, although
I might go back to assuming it again in a bit. Last I checked, OpenSolaris
used a POSIXy shell, but plain Solaris still didn't by default, and I tend
to try to write for "works in /bin/sh everywhere".
Seebs
> On comp.unix.shell, Seebs <usenet...@seebs.net> wrote:
>> One of my primary Unix boxes is a Mac.
> It's either Unix or Mac. It can't be both.
Bull.
$ uname -a
Darwin laptop-seebs-net.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31
22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386
It has a /bin/sh which is a POSIX sh. It conforms to any test of Unix-ness
I can think of.
Macs have been Unix for most of the last decade.
>> Which, *out of the box*, has many files with spaces in their
>> names (though none with newlines).
> Unix OSes do not have spaces or newlines in their filenames.
Sure they do. They have absolutely ANYTHING in their filenames except NUL
and /.
> My Slackware Linux certainly does not. It is a Unix clone.
It certainly can:
$ touch ' spacenl
see'
Behold, a file name which contains a space and a newline. Guaranteed to
work on any conforming Unix-like system.
> "Oh well"? Who is forcing you to use these flawwed OSes?
I have no alternatives on offer. Since a system that wishes to claim
to be "unix" *MUST* support filenames containing both spaces and newlines,
what else am I gonna do? This is comp.unix.shell, not
comp.what-i-wish-unix-had-been-maybe.shell.
> Thanks, but what works for me is to use a decent OS.
Your OS is no different.
> Slackware with a basic GUI (no 'desktop environment').
Doesn't matter. If it's UNIX-compatible, it is possible for someone
somewhere to create a file with a space or newline in its name.
Look, I can understand not being very cheerful about it, and I indeed
work on a product which checks for spaces in project directory paths
and refuses to try to work in them (although we keep fixing bits and
pieces up). But asserting that there's some flaw in the OS when it's a
100% standard UNIX feature that every UNIX has provided is silly.
Stephane CHAZELAS
> On 2009-11-06, pk <p...@pk.invalid> wrote:
>> set -f
>
> I'm not sure how portable it is.
>
>> but that still can't do anything against filenames with spaces.
You do
IFS='
'
for that (that still doesn't solve the problems of filenames
with newlines).
> Yup. That's why find's had -exec forever, and why xargs uses newlines.
[...]
xargs uses newlines, spaces, tabs, single and double quotes and
backslashes.
For xargs you need to preprocess the input with sed 's/./\\&/g'
to escape all those but newline.
There is a way to post-process the output of find so that it is
suitable for xargs, using a trick like find .//. | awk ... |
xargs ...
The awk script detects the start of new file thanks to the //
that can't appear anywhere else in the file, and is therefore
able to escape the newline characters that are part of
filenames.
--
Stï¿œphane
Seebs
> backslashes.
Er, what?
The man page says nothing about the quotes and backslashes, just newline,
space, and tab.
> The awk script detects the start of new file thanks to the //
> that can't appear anywhere else in the file, and is therefore
> able to escape the newline characters that are part of
> filenames.
Neat trick!
Sidney Lambe
> On 2009-11-06, Sidney Lambe <sidne...@nospam.invalid> wrote:
>
>> On comp.unix.shell, Seebs <usenet...@seebs.net> wrote:
>>
>>> One of my primary Unix boxes is a Mac.
>
>> It's either Unix or Mac. It can't be both.
>
> Bull.
>
> $ uname -a Darwin laptop-seebs-net.local 10.0.0 Darwin
> Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009;
> root:xnu-1456.1.25~1/RELEASE_I386 i386
>
> It has a /bin/sh which is a POSIX sh. It conforms to any test
> Iof Unix-ness can think of.
>
> Macs have been Unix for most of the last decade.
No. They have been Macs.
I have played with a few. They absolutely do _not_ behave
like Unix or Linux.
>
>>> Which, *out of the box*, has many files with spaces in their
>>> names (though none with newlines).
>
>> Unix OSes do not have spaces or newlines in their filenames.
>
> Sure they do. They have absolutely ANYTHING in their filenames
> except NUL and /.
What they _can_ do and what rational people do with them are
two different things.
You can also use your laptop as a cutting board, but sensible
people do not.
>
>> My Slackware Linux certainly does not. It is a Unix clone.
>
> It certainly can:
>
> $ touch ' spacenl see'
>
> Behold, a file name which contains a space and a newline.
> Guaranteed to work on any conforming Unix-like system.
Yes. and you could also do this:
rm -rf /
But intelligent people do not.
If you want to allow files with unnecessary and problem-creating
name on your computer, knock yourself out.
And have fun dealing with the problems that result.
But if you are going to send files to me they better have
normal names or all of my networking tools will reject them.
Sid
Casper H.S. Dik
>Yes. and you could also do this:
>rm -rf /
>But intelligent people do not.
# rm -rf /
rm of / is not allowed
What is it supposed to do? :-)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Seebs
> No. They have been Macs.
>
> I have played with a few. They absolutely do _not_ behave
> like Unix or Linux.
Given that last I heard they're certified UNIX (tm)... Well, they sure
seem like Unix to me.
I usually have a shell open running screen with a few screens on my
local machine (the Mac) and a few on my NetBSD server.
I can forget which is which, because they have the same commands with
the same options and react in the same way to most of the things I'm
likely to do.
> What they _can_ do and what rational people do with them are
> two different things.
The robustness principle applies: Don't generate filenames with spaces
in them, but be prepared for them.
> If you want to allow files with unnecessary and problem-creating
> name on your computer, knock yourself out.
It's not a question of what *I* allow. They're allowed. Do I actually
take the time to vet every single program I run to ensure that it somehow
prevents anyone from ever creating a name with a space? Have I modified
'tar' so that it will "fix" such names during unpacking? No.
So in practice, if I exchange files, there will be filenames with spaces
in them.
> And have fun dealing with the problems that result.
Well, that's the thing. With a little bit of caution and thinking ahead,
no problems result.
> But if you are going to send files to me they better have
> normal names or all of my networking tools will reject them.
I'd view that as a bug in the tools. The spec's pretty clear, and
handwaving something away as "not intelligent" buys you nothing.
The probability is pretty much unity that there is at least one person
out there who is smarter than you by any test you care to invent
other than the question-begging "does X use spaces in file names", who knows
Unix and the shell better than you, and who uses spaces in file names
occasionally. They're allowed. Maybe they shouldn't have been, but they
are, and here we are, and we can deal with them or not.
I generally aim to write robust code rather than code contingent on the
assumption that everyone else is smart and also agrees with me.
Rakesh Sharma
find . \
-type f \
-name '*.jsp' \
-exec sh -c '
shift "$1"
for arg
do
_full=`printf "%s/\\n" "$arg"`
_file=`expr "${_full}" : ".*/\(.*/\)"`
set ${1+"$@"} "${_file}"; shift
done
cp -ip "$@" /tmp/destdir/
' 2 1 {} +
Sidney Lambe
>> No. They have been Macs.
>>
>> I have played with a few. They absolutely do _not_ behave
>> like Unix or Linux.
>
> Given that last I heard they're certified UNIX (tm)... Well, they sure
> seem like Unix to me.
Great. You can get food full of pesticides that are certified organic,
too.
I've played with Macs on several occassions and they do not
behave like Unix or Linux. That's why they call them ->>>> MACS,
not Unix, I'm pretty sure.
Clearly, you are one of these neurotics we encounter so often on the
Internet who just can't sleep unless he can bully someone into seeing
things his way.
Get this through your head: I think you are wrong. There's simply
nothing you can do about it.
Now shut the fuck up.
[delete]
Done.
Sid
Seebs
> I've played with Macs on several occassions and they do not
> behave like Unix or Linux.
Shame you can't name a single actual difference in their behaviors that we
could talk about.
> That's why they call them ->>>> MACS,
> not Unix, I'm pretty sure.
Huh, you mean like the way they call them "cats" rather than "mammals",
proving that they're not mammals?
> Clearly, you are one of these neurotics we encounter so often on the
> Internet who just can't sleep unless he can bully someone into seeing
> things his way.
> Get this through your head: I think you are wrong. There's simply
> nothing you can do about it.
> Now shut the fuck up.
Another milspec irony meter blown to shreds. *sigh*
I certainly grant that you think I'm wrong. Well, "think" might be a bit
strong a term. You appear to *believe* that I'm wrong. I normally reserve
the word "think" for a process which involves some kind of reasoning, possibly
from evidence.
But what we've seen so far is cussing, insults, ranting, and not a single
concrete piece of evidence to support your claim that modern OS X "does
not behave like Unix". You haven't even articulated what you *mean* by
that, really. You certainly feel, very strongly, that filenames oughtn't
to have spaces in them, and that if they do, it is in some unspecified way
the fault of people other than you.
You have yet to offer evidence or argumentation in support of this
position. You haven't suggested why we should listen to you, rather than
to the many experienced shell programmers who regard it as an essential
practice to take care to handle file names which contain whitespace. Since
people who have arguments usually present them, I'm inferring that you
haven't got an argument.
The irony of your "shut the fuck up" response notwithstanding, I don't see
why you think I'm trying to "bully" you into anything. I'm not the one
using cussing as a substitute for argument. I'm offering evidence and
arguments establishing that your position is factually incorrect,
historically unsupported, and pragmatically stupid. It is entirely possible
that, with modern neuroscience, it would be possible to measure the degree
to which I care whether you come to perceive this. If I were writing you
in email, then I would be primarily concerned with your opinions... But I'm
not. I'm posting to Usenet, where my interest is in making sure that newbies
who don't know any better don't get suckered by your totally unsupported
and historically untrue claims about what Unix is like.
Note that even if we grant the spaces without argument, your solution
is still broken for a lot of real world cases, because you didn't allow
for command line length limits, so it's not as if winning this would
salvage it.
Casual poking around a handful of Unix hard drives results in dozens to
hundreds of files with spaces in their names, across a broad range of
BSD systems, Linux systems, and others. Don't like it? Too bad. Reality
wins over dogma.
Sidney Lambe
wrote:
He actually replied to this.
And he obviously thinks I'm going to read it.
Proof positive that he's just another stinking troll.
<plonk>
Sid
Seebs
Yes.
> And he obviously thinks I'm going to read it.
No.
> Proof positive that he's just another stinking troll.
Proof positive that you don't understand Usenet. The point of public
posts is to address an audience. The audience, I think, has a pretty clear
notion of which of us is the troll. :)
Maxwell Lol
> I've played with Macs on several occassions and they do not
> behave like Unix or Linux. That's why they call them ->>>> MACS,
> not Unix, I'm pretty sure.
Being "pretty sure" has never stopped you from being wrong before,
Alan. Darwin is based on the Mach kernel, which is based on the BSD
kernel. In fact, one might say that Darwin has a better UNIX pedegree
than Linux because of it's derivation from BSD Unix. Linux was
developed as a Unix clone.
But do contine on with your "expert" opinion.....
Maxwell Lol
> Proof positive that you don't understand Usenet. The point of public
> posts is to address an audience.
Trolls like Alan don't see USENET that way. They just look for a way
they can exhibit their trollish behavior, and by ignoring facts and
honest critism, they blindly claim victory in an room they imagine is
filled with worshipers, but in reality is empty.
Sidney Lambe
You just don't get it, headsick troll: When I tell someone
on the usenet to shut the fuck up, that's exactly what
they do. Forever.
You are no longer allowed to use the Usenet to send messages
to me. No, I don't have my filter kill your posts. I just
look at your post and the response to it from the sockpuppets
that all dickless and mentally ill motormouths employ, and
dump them.
You just can't make people read your articles, feeb, That's
the way it is.
I don't need to read your articles because you don't know anything
worth knowing and couldn't harm a fly.
You are just another fat-assed, dickless loser with a computer.
And you _will_ find someone else to talk to.
You have no choice in the matter.
:-)
If you don't like it, you can alway complain to your Mommy.
You know: the nice lady who lets you use her computer and
credit card.
Sid
Seebs
> You just don't get it, headsick troll: When I tell someone
> on the usenet to shut the fuck up, that's exactly what
> they do. Forever.
This is some kind of koan, right?
> You are no longer allowed to use the Usenet to send messages
> to me.
Okay.
> You just can't make people read your articles, feeb, That's
> the way it is.
But I can, apparently, make you respond ANYWAY. That is AWESOME.
I HAVE MIND CONTROL RAYS!!!!
> I don't need to read your articles because you don't know anything
> worth knowing and couldn't harm a fly.
Couldn't, or wouldn't? This matters!
> You are just another fat-assed, dickless loser with a computer.
Solidarity, bro.
> And you _will_ find someone else to talk to.
I have no doubt in this matter.
> If you don't like it, you can alway complain to your Mommy.
>
> You know: the nice lady who lets you use her computer and
> credit card.
I haven't been insulted like this since third grade.
Anyway, you have my sincerest apologies for my inexplicable decision to
respond to your posts without looking you up first. Had I known you were
so justifiably famous, I would never have responded in a way which implied
sincere interest in your thoughts.
But please, continue. It's amusing, and while you're no Nilged, you
certainly make up in sheer impotent rage what you lack in total
non-sequiturs.
stan
>
>
> On comp.unix.shell, Seebs <usenet...@seebs.net> wrote:
>> On 2009-11-06, Sidney Lambe <sidne...@nospam.invalid> wrote:
>>> No. They have been Macs.
>>>
>>> I have played with a few. They absolutely do _not_ behave
>>> like Unix or Linux.
>>
>> Given that last I heard they're certified UNIX (tm)... Well, they sure
>> seem like Unix to me.
>
> Great. You can get food full of pesticides that are certified organic,
> too.
>
> I've played with Macs on several occassions and they do not
> behave like Unix or Linux. That's why they call them ->>>> MACS,
> not Unix, I'm pretty sure.
When was the last time you played with a Mac? In days gone by they
bore no resemblance to Unix/Linux but today they are based on BSD. Are
you saying BSD bears no relation to Unix? I don't use either Mac or
BSD and I find BSD, especially the older versions, a very strange
environment. But I can't agree that they "do not behave like Unix or Linux".
Maxwell Lol
>> I've played with Macs on several occassions and they do not
>> behave like Unix or Linux. That's why they call them ->>>> MACS,
>> not Unix, I'm pretty sure.
>
> When was the last time you played with a Mac?
I think "play" is the essence of Sidney/Alan.
He certainly can't work in the computer industry.
Seebs
> He certainly can't work in the computer industry.
Don't you wish:
http://thedailywtf.com/
Michael Paoli
> On comp.unix.shell, Seebs <usenet...@seebs.net> wrote:
>
>
>
> > In particular,
> > what do you do if the find yields files with spaces or newlines
> > in their names, etc.?
>
> I don't have any files with names like that. I don't allow them
> on my box. That's Windows garbage. So I can't answer your question.
Unix absolutely allows filenames with space and newline in them, and
has
for at least 3 decades, if not since the origin of Unix. One should
be
prepared for such cases.
Unix allows at least all ASCII characters except the ASCII null
character and / (directory separator).
> Can find deal with files like that?
Absolutely.
$ ls -a
. ..
$ echo foo > 'a b
> c d'
$ ls | cat
a b
c d
$ ls -l * | cat
-rw------- 1 michael users 4 Nov 8 11:38 a b
c d
$ find . -type f -print
./a b
c d
$ find . -type f -exec cat -- \{\} \;
foo
$
Sidney Lambe
> On Nov 5, 2:42 pm, Sidney Lambe <sidne...@nospam.invalid>
> wrote:
>
>> On comp.unix.shell, Seebs <usenet...@seebs.net> wrote:
>>
>> > On 2009-11-05, Sidney Lambe <sidne...@nospam.invalid>
>> > wrote:
>>
>> cp $(find ...) /dest/dir
>>
>> > In particular, what do you do if the find yields files with
>> > spaces or newlines in their names, etc.?
>>
>> I don't have any files with names like that. I don't allow
>> them on my box. That's Windows garbage. So I can't answer your
>> question.
>
> Unix absolutely allows filenames with space and newline in
> them, and has for at least 3 decades, if not since the origin
> of Unix. One should be prepared for such cases. Unix allows at
> least all ASCII characters except the ASCII null character and
> / (directory separator).
Yes. That's been posted several times on this thread.
I suggest that in the future you read threads before
wasting everyone's time and bandwidth with redundant material.
>
>> Can find deal with files like that?
>
> Absolutely.
This too has been covered.
[delete]
Sid
Maxwell Lol
> Don't you wish:
> http://thedailywtf.com/
First time I've seen this site. I LOVE it.
Right up there with the Shark Tank blog - one of my favs.
Maxwell Lol
>> Unix absolutely allows filenames with space and newline in
>> them, and has for at least 3 decades, if not since the origin
>> of Unix. One should be prepared for such cases. Unix allows at
>> least all ASCII characters except the ASCII null character and
>> / (directory separator).
>
> Yes. That's been posted several times on this thread.
>
> I suggest that in the future you read threads before
> wasting everyone's time and bandwidth with redundant material.
Especially the threads with people trying to intelligently disagree
with the Alan/Sid troll. All they get are insults and/or Sid with his
hands over his eyes saying "I'm not reading these responses...."
Oh - and the responses saying that everyone is just a sock puppet.
Seebs
> with the Alan/Sid troll. All they get are insults and/or Sid with his
> hands over his eyes saying "I'm not reading these responses...."
Yeah. I have to admit, I was totally surprised by the sheer stupidity of
it.
My new hobby: Getting a file into slackware's core distro with a space
in its name, and calling Sid on it a year or so later. :P
Geoff Clare
> On 2009-11-06, Stephane CHAZELAS <stephane...@yahoo.fr> wrote:
>> xargs uses newlines, spaces, tabs, single and double quotes and
>> backslashes.
>
> Er, what?
>
> The man page says nothing about the quotes and backslashes, just newline,
> space, and tab.
Which man page?
SUSv4 says:
A string of zero or more non-double-quote ('"') characters and
non-<newline> characters can be quoted by enclosing them in
double-quotes. A string of zero or more non-<apostrophe> (''')
characters and non-<newline> characters can be quoted by enclosing
them in <apostrophe> characters. Any unquoted character can be
escaped by preceding it with a <backslash>.
--
Geoff Clare <net...@gclare.org.uk>
Seebs
> Which man page?
Whichever one I grabbed first.
> A string of zero or more non-double-quote ('"') characters and
> non-<newline> characters can be quoted by enclosing them in
> double-quotes. A string of zero or more non-<apostrophe> (''')
> characters and non-<newline> characters can be quoted by enclosing
> them in <apostrophe> characters. Any unquoted character can be
> escaped by preceding it with a <backslash>.
Interesting.