Why preceed a "rm" command with a backslash?
DavidFilmer
about.
In every case, there is a backslash before the "rm", such as:
\rm -f foo.txt
I see no reason to escape the "r" and I don't see any other purpose
for the backslash.
Does anyone know why might the original developer might have included
this backslash?
Thanks!
Sidney Lambe
That runs rm as if you had entered /usr/bin/rm.
The idea is to run it without any options: It could be renamed
with an alias to something like rm -i, which is
pretty common.
Sid
--
Shell Interface Mailing List
screening address: usenet4444
[AT] gmail (dot) com
Randal L. Schwartz
Sidney> That runs rm as if you had entered /usr/bin/rm.
Sidney> The idea is to run it without any options: It could be renamed
Sidney> with an alias to something like rm -i, which is
Sidney> pretty common.
And I argue, very wrong.
But that doesn't keep idiots from doing it.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Chris F.A. Johnson
>>>>>> "Sidney" == Sidney Lambe <sidne...@nospam.invalid> writes:
>
>Sidney> That runs rm as if you had entered /usr/bin/rm.
>Sidney> The idea is to run it without any options: It could be renamed
>Sidney> with an alias to something like rm -i, which is
>Sidney> pretty common.
>
> And I argue, very wrong.
Absolutely!
> But that doesn't keep idiots from doing it.
Some Linux distributions do it. That's why I always start my
.bashrc file with "unalias -a".
--
Chris F.A. Johnson, author <http://cfaj.freeshell.org/shell/>
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
Stachu 'Dozzie' K.
>>>>>> "Sidney" == Sidney Lambe <sidne...@nospam.invalid> writes:
>
>Sidney> That runs rm as if you had entered /usr/bin/rm.
>Sidney> The idea is to run it without any options: It could be renamed
>Sidney> with an alias to something like rm -i, which is
>Sidney> pretty common.
>
> And I argue, very wrong.
>
> But that doesn't keep idiots from doing it.
I don't know if it is wrong, but I'm sure it does force people to learn
to use "rm -rf" all the time and *that is* wrong.
--
Stanislaw Klekot
Sidney Lambe
> On 2009-09-02, Randal L. Schwartz wrote:
>>>>>>> "Sidney" == Sidney Lambe <sidne...@nospam.invalid> writes:
>>
>>Sidney> That runs rm as if you had entered /usr/bin/rm.
>>Sidney> The idea is to run it without any options: It could be renamed
>>Sidney> with an alias to something like rm -i, which is
>>Sidney> pretty common.
>>
>> And I argue, very wrong.
Not that I've seen. You offer no explanation for your opinion
at all.
>
> Absolutely!
>
>> But that doesn't keep idiots from doing it.
>
> Some Linux distributions do it. That's why I always start my
> .bashrc file with "unalias -a".
Chris hates aliases but he won't explain why either.
Myself and a lot of other people think he's full of it on this one
and his lack of arguments to back up his opinion makes him
look rather foolish.
>
A lot of experts think it is a very good idea for root to
alias rm and mv to rm -i and mv -i for obvious reasons.
I seem to recall you railing against people for running as
root because if they make a mistake, as in getting careless
with rm or mv, they could really mess up their system.
The -i alias is a pretty good idea for root.
Chris needs to learn consistency.
Casper H.S. Dik
>>>>>> "Sidney" == Sidney Lambe <sidne...@nospam.invalid> writes:
>Sidney> That runs rm as if you had entered /usr/bin/rm.
>Sidney> The idea is to run it without any options: It could be renamed
>Sidney> with an alias to something like rm -i, which is
>Sidney> pretty common.
>And I argue, very wrong.
>But that doesn't keep idiots from doing it.
Your ksh script should not read $ENV, .kshrc or any other
of your aliases so \rm would be wrong for scripts anyway.
Old ksh (88) allowed this:
$ alias \\rm='echo foo'
$ \rm
foo
And C-shell allows this:
% alias /bin/rm echo ha ha
% /bin/rm foo
ha ha foo
There are options which disable sourcing .kshrc, .cshrc,, etc
and that is what should be used.
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.
Casper H.S. Dik
>A lot of experts think it is a very good idea for root to
>alias rm and mv to rm -i and mv -i for obvious reasons.
If you have that as an alias, you will quickly depend on
it and one day you will run as root without the alias and
you'll be looking for your backups.
Better think before you hit the carriage return and not
after.
DaveG
> Sidney Lambe <sidne...@nospam.invalid> writes:
>
>>A lot of experts think it is a very good idea for root to alias rm and
>>mv to rm -i and mv -i for obvious reasons.
>
> If you have that as an alias, you will quickly depend on it and one day
> you will run as root without the alias and you'll be looking for your
> backups.
>
> Better think before you hit the carriage return and not after.
Without getting in to the political whys and wherefores of this argument,
I'd just like to add that in general I prefer to work with the "raw"
commands etc too. My reasoning behind that attitude is that I often work
on other peoples systems so I don't want to be in a position of getting
used to a "customised" system such that I expect non-standard behavior.
If their system is customised, then I have to work within that framework.
On the other hand, most people only ever work on their "own" systems
(home/work/whatever) so if they want to standardise on their own specific
customisations, then that's fine too.
--
You cannot simply assume someone is honest
just because they are not an MP.
Sidney Lambe
> Sidney Lambe <sidne...@nospam.invalid> writes:
>
>>A lot of experts think it is a very good idea for root to alias
>>rm and mv to rm -i and mv -i for obvious reasons.
>
> If you have that as an alias, you will quickly depend on it and
> one day you will run as root without the alias and you'll be
> looking for your backups.
Wrong. I would never run as root on a new OS without checking
things like that.
>
> Better think before you hit the carriage return and not after.
Better to do that _and_ use the safety measures.
I'll bet you don't wear a seat belt when you drive because you
think you can't make a mistake.
The morgues are filled with people like you.
>
> Casper -- Expressed in this posting are my opinions.
No kidding.
> They are in no way related to opinions held by my employer, Sun
> Microsystems.
I can't think of any reason to suspect they were. Wouldn't even
have known you worked for them if you hadn't mentioned it here.
And couldn't care less.
> Statements on Sun products included here are not
> gospel and may be fiction rather than truth.
Mumbo-Jumbo.
Anyone who believes anything a corporation says, even if it
is in writing and signed by the CEO and CFO, is an idiot.
DavidFilmer
> That runs rm as if you had entered /usr/bin/rm.
Sorry, I don't get it. 'rm' is in my path (/usr/bin/rm). So, if I
just type 'rm' it should run /usr/bin/rm. How does the backslash
affect the behavior of the script or the command?
> The idea is to run it without any options
In this script, every 'rm' command specifies the "force" modifier,
"\rm -f ..." If the idea is to avoid using command line options, this
script doesn't get it.
thx
Mick
Let us rephrase it:
With a backslash, you escape any alias. This is frequently used as a
workaround on sites which have aliases like alias rm=rm -i when you want
to bypass the alias.
MickG
Keith Keller
> On Sep 1, 5:44�pm, Sidney Lambe <sidneyla...@nospam.invalid> wrote:
>> That runs rm as if you had entered /usr/bin/rm.
>
> Sorry, I don't get it. 'rm' is in my path (/usr/bin/rm). So, if I
> just type 'rm' it should run /usr/bin/rm. How does the backslash
> affect the behavior of the script or the command?
If you have, for example,
alias rm=rm -i
then \rm will run regular rm, without -i (which is not a default
option), whereas rm will run rm -i.
Now, depending on how the script itself is called, and what your
environment is like, an alias in your current shell may or may not
propagate to the script. If you run the script as bash yourscript,
the alias won't make the script, because it's a noninteractive
nonlogin shell. If you run it as . yourscript, then it will have
any aliases in your current shell, because the . (or, equivalently,
source yourscript) runs the commands in yourscript in the current shell,
not a new shell.
Read man bash, and look for the INVOCATION section, for how bash
determines its environment.
>> The idea is to run it without any options
>
> In this script, every 'rm' command specifies the "force" modifier,
> "\rm -f ..." If the idea is to avoid using command line options, this
> script doesn't get it.
Well, it does sound like this script is a bit whacked. :) It could be
that this developer was not entirely competent. Or perhaps just wanted
to be really thorough. If I wanted to be sure of the command line and
arguments, I'd have done something like
/usr/bin/rm -f blah blah ...
instead of using a backslash, to be more explicit about what I wanted
(and avoid the confusion that you're currently experiencing).
Are you mainly trying to figure out what's going on, or are you having
some difficulty with this script? If the latter, perhaps you can be
more specific what the problem is.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
DavidFilmer
francisco.ca.us> wrote:
> If you have, for example,
> alias rm=rm -i
> then \rm will run regular rm, without -i (which is not a default
> option), whereas rm will run rm -i.
Ah, got it now. Thanks.
> Are you mainly trying to figure out what's going on, or are you having
> some difficulty with this script?
I'm porting it to Perl. So I need to understand how this command
behaves so I can duplicate the behavior. I've never overloaded Perl's
unlink() command, so that should do nicely.
thx!
Barry Margolin
Mick <mic...@verizon.net> wrote:
But don't scripts have to go out of their way to inherit aliases, it
doesn't happen by default, right? So why would a script have to worry
about aliases if it didn't explicitly ask to import them?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Mick
> In article <h7n0mh$g11$1...@news.eternal-september.org>,
> Mick <mic...@verizon.net> wrote:
>
>> DavidFilmer wrote:
>>> On Sep 1, 5:44 pm, Sidney Lambe <sidneyla...@nospam.invalid> wrote:
>>>> That runs rm as if you had entered /usr/bin/rm.
>>> Sorry, I don't get it. 'rm' is in my path (/usr/bin/rm). So, if I
>>> just type 'rm' it should run /usr/bin/rm. How does the backslash
>>> affect the behavior of the script or the command?
>>>
>>>> The idea is to run it without any options
>>> In this script, every 'rm' command specifies the "force" modifier,
>>> "\rm -f ..." If the idea is to avoid using command line options, this
>>> script doesn't get it.
>>>
>>> thx
>> Let us rephrase it:
>> With a backslash, you escape any alias. This is frequently used as a
>> workaround on sites which have aliases like alias rm=rm -i when you want
>> to bypass the alias.
>
> But don't scripts have to go out of their way to inherit aliases, it
> doesn't happen by default, right? So why would a script have to worry
> about aliases if it didn't explicitly ask to import them?
>
Yes indeed, but it sounds as of the original author of the script didn't
understand that and I was trying to simplify to the op what the normal
use for \rm would be. Of course if the script set alias rm="rm -i"
earlier then a later use of \rm would override that. Since we don't know
he full content of this particular script . . .
MickG
--
One of the main causes of the fall of the Roman Empire was that, lacking
zero, they had no way to indicate successful termination of their C
Programs. (Robert Firth)
Barry Margolin
Mick <mic...@verizon.net> wrote:
I suspect your first guess is right. The script author is probably used
to using \rm interactively to evade aliases, and didn't realize that
this isn't necessary in scripts.
This is essentially what one of the first responders to the post said,
but in a more terse, confusing way.
Randal L. Schwartz
Sidney> A lot of experts think it is a very good idea for root to
Sidney> alias rm and mv to rm -i and mv -i for obvious reasons.
I would deny that they are experts.
It's like that old adage:
Q. what's the difference between a truck with rear wheel drive
and a truck with four wheel drive?
A. you'll have further to hike out of the woods *when* you get stuck
And similarly, all this alias does is move the problem down a bit further
into the trouble zone.
Bad idea.
Really bad.
Teach people "there is no un-rm", and they quickly learn how
dangerous it is.
Give them one more safety net, and they quickly learn to need two.
Bad idea.
Sidney Lambe
I guess you just aren't going to get it, then. Because the
situation has been explained thoroughly on this thread.
Sid
Keith Keller
Yep! unlink() will work perfectly. IIRC it calls the C unlink(2) under
the hood, which is what rm does when it removes files. There is a small
difference: perl's unlink, like unlink(2), can only unlink files, not
directories; rm -r can remove directories. But since your shell script
seems to only call rm -f, you should be fine with a plain unlink(). (If
you do need rm -rf, you can use the File::Path module.)
Andrew Smallshaw
> Casper H.S Dik <Caspe...@Sun.COM> wrote:
>
>> Sidney Lambe <sidne...@nospam.invalid> writes:
>>
>>>A lot of experts think it is a very good idea for root to alias
>>>rm and mv to rm -i and mv -i for obvious reasons.
>>
>> If you have that as an alias, you will quickly depend on it and
>> one day you will run as root without the alias and you'll be
>> looking for your backups.
>
> Wrong. I would never run as root on a new OS without checking
> things like that.
But that isn't the the only circumstance they can suddenly disppear.
All it takes is that you lose ENV from the environment when a
subshell opens and hey presto - no alias. That could be as simple
as a plain su to root for instance.
>> Better think before you hit the carriage return and not after.
>
> Better to do that _and_ use the safety measures.
I'm uncertain about that. In my experience things like this only
serve to get in your way and when you are getting annoyed and your
work is disrupted by the computer is when mistakes are most likely
to be made.
--
Andrew Smallshaw
and...@sdf.lonestar.org
Sidney Lambe
> On 2009-09-02, Sidney Lambe <sidne...@nospam.invalid> wrote:
>> Casper H.S Dik <Caspe...@Sun.COM> wrote:
>>
>>> Sidney Lambe <sidne...@nospam.invalid> writes:
>>>
>>>>A lot of experts think it is a very good idea for root to alias
>>>>rm and mv to rm -i and mv -i for obvious reasons.
>>>
>>> If you have that as an alias, you will quickly depend on it and
>>> one day you will run as root without the alias and you'll be
>>> looking for your backups.
>>
>> Wrong. I would never run as root on a new OS without checking
>> things like that.
>
> But that isn't the the only circumstance they can suddenly disppear.
> All it takes is that you lose ENV from the environment when a
> subshell opens and hey presto - no alias. That could be as simple
> as a plain su to root for instance.
So you wouldn't wear a seat belt because once in a while they
malfunction?
>>> Better think before you hit the carriage return and not after.
>>
>> Better to do that _and_ use the safety measures.
>
> I'm uncertain about that. In my experience things like this only
> serve to get in your way and when you are getting annoyed and your
> work is disrupted by the computer is when mistakes are most likely
> to be made.
>
The rm -i and mv -i aliases for root are a good idea. A safety
measure.
Sid
Kenny McCormack
Sidney Lambe <sidne...@nospam.invalid> wrote:
...
>The rm -i and mv -i aliases for root are a good idea. A safety
>measure.
Simply not true. The point is that if you are smart enough to use these
sorts of aliases responsibly, you are almost certainly smart enough to
not need them.
If you really want to do this sort of thing, the right thing to do is to
move the "rm" and "mv" programs to some hidden and/or protected
directory, then write interfaces to these commands with *different names*.
Then you teach your users to use "del" (for rm) and "move" (for mv).
And, as noted earlier, they can't access the real "rm" and "mv"
commands, since these are removed from their usual locations.
Mind you, I'm not recommending this course of action, and I'm sure there
are a lot of details that have to be attended to in order to make it
work, but that's exactly the point.
Sidney Lambe
> In article <4aa09609$1...@news.x-privat.org>, Sidney Lambe
> <sidne...@nospam.invalid> wrote: ...
>
>>The rm -i and mv -i aliases for root are a good idea. A safety
>>measure.
>
> Simply not true. The point is that if you are smart enough
> to use these sorts of aliases responsibly, you are almost
> certainly smart enough to not need them.
Intelligence has nothing to do with it. The most brilliant
person can become careless due to any number of causes.
>
> If you really want to do this sort of thing, the right thing to
> do is to move the "rm" and "mv" programs to some hidden and/or
> protected directory, then write interfaces to these commands
> with *different names*.
>
> Then you teach your users to use "del" (for rm) and "move" (for
> mv). And, as noted earlier, they can't access the real "rm"
> and "mv" commands, since these are removed from their usual
> locations.
>
> Mind you, I'm not recommending this course of action, and I'm
> sure there are a lot of details that have to be attended to in
> order to make it work, but that's exactly the point.
>
Moving rm and mv is not a very good idea. Too many applications/scripts
look for them there.
A better solution is to make del and move the name of functions that
create copies of the file in a directory reserved for the purpose
and then perform as usual.
move ()
{
cp "$1" /tmp/failsafe
mv "$1" "$2"
}
del ()
{
cp "$@" /tmp/failsafe
rm "$@"
}
(untested)
Then have a cron job that notifies you
if the dir gets too big, or something like
that.
Sid
Kenny McCormack
Sidney Lambe <sidne...@nospam.invalid> wrote:
>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>
>> In article <4aa09609$1...@news.x-privat.org>, Sidney Lambe
>> <sidne...@nospam.invalid> wrote: ...
>>
>>>The rm -i and mv -i aliases for root are a good idea. A safety
>>>measure.
>>
>> Simply not true. The point is that if you are smart enough
>> to use these sorts of aliases responsibly, you are almost
>> certainly smart enough to not need them.
>
>Intelligence has nothing to do with it. The most brilliant
>person can become careless due to any number of causes.
True at one level, of course, but not really the point.
>Moving rm and mv is not a very good idea. Too many applications/scripts
>look for them there.
The problem is that if you don't make the original commands unavailable,
then the users will just keep on using them (the original commands).
That's why the usual method is to alias them "in place", but as we have
seen, that has unintended consequences.
Moving them out is draconian, to be sure, but it is necessary.
Note, BTW, that this same exact thing has been debated innumerable times
over the years in these groups. All of the words posted each time are
pretty much the same...
Loki Harfagr
> In article <slrnhbl2sd.pn...@evergreen.net>, Sidney Lambe
> <sidne...@nospam.invalid> wrote:
... and ..., and alos maybe ...
> Moving them out is draconian, to be sure, but it is necessary.
say we've gotta move out 'coz city's movin'in?-)
>
> Note, BTW, that this same exact thing has been debated innumerable times
> over the years in these groups. All of the words posted each time are
> pretty much the same...
quite right, time for some helping hands.
Fleeble bam blupdah, dortannigannymsherk blubbah wap,
doo beep doh warp dont be warp be warp dont he bop da warp
no no no he dont weet or biktabarwoop na nah nor.
that should sum up the case about 'rm and its aliases'
in case of public demand some FU will be made about the
special 'mv' and 'cat<>' cousins but really, that
was already quite a flub in dee tyre to get this far ;-)
Sidney Lambe
I hope there's no out there stupid enough to mv rm and mv
to different names.
It would break their OS.
Sid
Loki Harfagr
...
> Note, BTW, that this same exact thing has been debated innumerable
>> times over the years in these groups. All of the words posted each time
>> are pretty much the same...
>>
>>
> I hope there's no out there stupid enough to mv rm and mv to different
> names.
>
> It would break their OS.
excuse my fr-FR but ITYM:
'Sticks and stones may break my bones'
Keith Keller
>
> I hope there's no out there stupid enough to mv rm and mv
> to different names.
>
> It would break their OS.
Of course it would not; it would just break utilities that rely on rm
and/or mv. But a resourceful and knowledgeable user can remove files
without rm. Just replace
rm [filespec]
with (this is just off the top of my head; one can probably be more
efficient about it)
ls [filespec] |perl -ple unlink
BTW, the pipe-to-perl trick is helpful when traversing a directory with
find to remove files. Often you might see people use -exec rm {} , but
that calls a shell for each file to be deleted. Piping the find output
to perl -ple unlink (or -nle, if you don't want the filenames printed)
doesn't.
Ooh, and I just found unlink! Not unlink(2) the library function, but
unlink(1) the executable. From the info page:
`unlink' deletes a single specified file name. It is a minimalist
interface to the system-provided `unlink' function.
So there you go! And, of course, mv is more or less functionally
equivalent to cp [filespec] && rm [filespec]. (I don't know if other
systems provide unlink; I have it on my CentOS box and my Slackware
box, default installs.)
Chris F.A. Johnson
> On 2009-09-23, Sidney Lambe <sidne...@nospam.invalid> wrote:
>>
>> I hope there's no out there stupid enough to mv rm and mv
>> to different names.
>>
>> It would break their OS.
>
> Of course it would not; it would just break utilities that rely on rm
> and/or mv. But a resourceful and knowledgeable user can remove files
> without rm. Just replace
>
> rm [filespec]
>
> with (this is just off the top of my head; one can probably be more
> efficient about it)
>
> ls [filespec] |perl -ple unlink
>
> BTW, the pipe-to-perl trick is helpful when traversing a directory with
> find to remove files. Often you might see people use -exec rm {} , but
> that calls a shell for each file to be deleted. Piping the find output
> to perl -ple unlink (or -nle, if you don't want the filenames printed)
> doesn't.
Nor does -exec rm {} +
--
Chris F.A. Johnson, author <http://cfaj.freeshell.org/shell/>
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
Janis Papanagnou
> On 2009-09-23, Sidney Lambe <sidne...@nospam.invalid> wrote:
>> I hope there's no out there stupid enough to mv rm and mv
>> to different names.
>>
>> It would break their OS.
>
> Of course it would not; it would just break utilities that rely on rm
> and/or mv. But a resourceful and knowledgeable user can remove files
> without rm. Just replace
>
> rm [filespec]
>
> with (this is just off the top of my head; one can probably be more
> efficient about it)
>
> ls [filespec] |perl -ple unlink
This must be a joke.
Wouldn't those admins also remove perl so that their users cannot do
anything "wrong"?
> [...]
> So there you go! And, of course, mv is more or less functionally
> equivalent to cp [filespec] && rm [filespec].
It isn't. You should _at least_ add some options to cp like -r -p ...
(probably -a on some systems) to preserve tree structure and stat
information.
Janis
Keith Keller
> On 2009-09-24, Keith Keller wrote:
>> BTW, the pipe-to-perl trick is helpful when traversing a directory with
>> find to remove files. Often you might see people use -exec rm {} , but
>> that calls a shell for each file to be deleted. Piping the find output
>> to perl -ple unlink (or -nle, if you don't want the filenames printed)
>> doesn't.
>
> Nor does -exec rm {} +
Ooh, never knew that one! And right below that in the man page is the
-execdir option, which I'll have to play around with.
See, even ''Sid'' threads can result in something useful. :)
Randal L. Schwartz
Keith> rm [filespec]
Keith> with (this is just off the top of my head; one can probably be more
Keith> efficient about it)
Keith> ls [filespec] |perl -ple unlink
That's scarily bad. I have something akin to my once-famous "useless use of
cat award" that I used to give out for "dangerous use of ls". You've just
triggered it for me.
Here's the point. When you say:
ls *.c
The following happens:
1) the shell expands *.c, into say: aaa.c, bbb.c, ccc.c
2) the shell fires up "ls aaa.c bbb.c ccc.c"
3) ls wakes up, and says "oh, I have command line args... let's go list those"
4) ls verifies aaa.c is there, and it's a file, so it prints it out
5) ls verifies bbb.c is there, and it's a file, so it prints it out
6) ls verifies ccc.c is there, and it's a file, so it prints it out
Why the heck would you make both the shell *and* ls go figure out what files
those are?
And don't get me started about what would have happened if you had a directory
that matched *.c. That's a total tangent here, and also bad.
Now, let's go on to the dangerous part, more than just the wasted-CPU part.
"perl -ple" reads newline delimited names. (By the way, it also needlessly
prints them... maybe you wanted "-nle".)
Suppose you have a file with a name of "aaa\nbbb.c". Yup, that's legal.
Now your ls will print:
aaa
bbb.c
but Perl sees those as two separate names. If you have an "aaa",
whoops, I mean, "now that you had an aaa", because it's now gone, even
though it didn't match "*.c".
Oops.
So, slow, and needlessly dangerous. Bad all around.
Here's what I think you *might* have meant:
perl -e 'unlink @ARGV' [filespec]
1) no useless use of ls
2) no danger from filenames containing newlines
3) no firing off two processes to do what one can do
And they say shell programming is simple. {sigh}
Keith Keller
>
> That's scarily bad. I have something akin to my once-famous "useless use of
> cat award"
"Once-famous"? It is still famous, Randal! I still see UUOC awarded
every few months.
> Why the heck would you make both the shell *and* ls go figure out what files
> those are?
Because I was too lazy to figure out the proper command line, knowing
someone would do it for me. :) Seriously, it was literally the first
thought in my head, and I knew it was wasteful.
> "perl -ple" reads newline delimited names. (By the way, it also needlessly
> prints them... maybe you wanted "-nle".)
I like -p on occasion; I use it when I pipe my find output to perl -ple
unlink (which still qualifies as dangerous by your definition), so I can
see that the correct files are being deleted. (Of course I still
generally do the find by itself first, so I can see the output anyway.)
> Suppose you have a file with a name of "aaa\nbbb.c". Yup, that's legal.
Anyone who embeds a newline into a filename deserves problems. ;-)
I have seen filenames with newlines, I think maybe once or twice in
the past ten years.
> Here's what I think you *might* have meant:
>
> perl -e 'unlink @ARGV' [filespec]
Yep, thank you for providing the proper method.
> And they say shell programming is simple. {sigh}
Anyone who says that doesn't know what he is doing. ''Sid'' says
this all the time.
Randal L. Schwartz
>> Suppose you have a file with a name of "aaa\nbbb.c". Yup, that's legal.
Keith> Anyone who embeds a newline into a filename deserves problems. ;-)
Keith> I have seen filenames with newlines, I think maybe once or twice in
Keith> the past ten years.
Well, there was a very embarassing error for Apple a few years ago
for the 10.3 to 10.4 upgrade as I recall. Apparently, if you had
a space in your home disk name, all sorts of files got deleted.
So, the moral is, no matter how rare you think something is, that's *NO
EXCUSE* for not doing the right thing for *all* possible characters.
Maxwell Lol
>>>>>> "Keith" == Keith Keller <kkeller...@wombat.san-francisco.ca.us> writes:
>
>>> Suppose you have a file with a name of "aaa\nbbb.c". Yup, that's legal.
>
> Keith> Anyone who embeds a newline into a filename deserves problems. ;-)
> Keith> I have seen filenames with newlines, I think maybe once or twice in
> Keith> the past ten years.
>
> Well, there was a very embarassing error for Apple a few years ago
> for the 10.3 to 10.4 upgrade as I recall. Apparently, if you had
> a space in your home disk name, all sorts of files got deleted.
>
> So, the moral is, no matter how rare you think something is, that's *NO
> EXCUSE* for not doing the right thing for *all* possible characters.
That's sort of high-and-mighty...., Randal
There's a big difference for writing a script that will run on any
system anywhere, and writing a script on a filesystem that you own and control
100% and NEVER allow filenames with non-printing on it.
I NEVER allow non-printing characters in filenames on the systems I
use for myself, and where I am the only user.
Randal L. Schwartz
Maxwell> I NEVER allow non-printing characters in filenames on the systems I
Maxwell> use for myself, and where I am the only user.
And you've *never ever ever* quickly grabbed one of your scripts for
an email message to someone else who asked "hey, I need to do X, do you
have anything that does X?"
Really?
NEVER EVER EVER?
And you *lock up* your bin so your fellow users can't "borrow" scripts
that look interesting?
ALWAYS? Your $HOME/bin is mode 700 right now? Really?
Right. I didn't think so.
The problem with writing scripts is that they always outlive the original
task, and the original user.
Hence, WRITE IT CORRECT. The differential cost isn't huge. It just takes
diligence.
DON'T WASTE TIME WRITING A LIMITED SCRIPT.
There ya go.
Keith Keller
> mer...@stonehenge.com (Randal L. Schwartz) writes:
>>
>> Well, there was a very embarassing error for Apple a few years ago
>> for the 10.3 to 10.4 upgrade as I recall. Apparently, if you had
>> a space in your home disk name, all sorts of files got deleted.
>>
>> So, the moral is, no matter how rare you think something is, that's *NO
>> EXCUSE* for not doing the right thing for *all* possible characters.
>
> That's sort of high-and-mighty...., Randal
>
> There's a big difference for writing a script that will run on any
> system anywhere, and writing a script on a filesystem that you own and control
> 100% and NEVER allow filenames with non-printing on it.
Well, except "\n" and space are printing characters, you just can't
distinguish them readily from other whitespace in the terminal. And,
unfortunately, file names with spaces are quite common on Windows or
OS X, and if a linux box is the file server for those clients, it has to
handle spaces in filenames well.
> I NEVER allow non-printing characters in filenames on the systems I
> use for myself, and where I am the only user.
That's part of Randal's point--there are so many situations where you
might think you're the only user, then something unexpected happens, you
press a box into service, and you're no longer the only user, and you
can't restrict filenames for one reason or another. It happens.
That said, you still shouldn't use "\n" in file names! That's pretty
much completely insane.
I mentioned that in the past ten years or so I'd seen "\n" in filenames
two or three times--all of those times it was an error in saving, so it
was never intended to be saved with a newline. The way I found this was
with my backup script, which did pretty something similar to what Randal
described--it tried to back up "filename" which didn't exist.
Fortunately it also complained on stderr, so I was able to check with
the user in each situation. (This script now sends an explicit error if
the filename has a newline embedded in it; the original error was a bit
unclear.)
Maxwell Lol
>>>>>> "Maxwell" == Maxwell Lol <nos...@com.invalid> writes:
>
> Maxwell> I NEVER allow non-printing characters in filenames on the systems I
> Maxwell> use for myself, and where I am the only user.
>
> And you've *never ever ever* quickly grabbed one of your scripts for
> an email message to someone else who asked "hey, I need to do X, do you
> have anything that does X?"
>
> Really?
>
> NEVER EVER EVER?
Yes. Never ever EVER.
If I give a script to someone, and I want it to work for any system
anywhere, I make sure it does that.
> And you *lock up* your bin so your fellow users can't "borrow" scripts
> that look interesting?
Yes. I do. I run 6 Linux machines at home, and have used Linux at home for more than 10 years.
No one else has access to these machine.
>
> ALWAYS? Your $HOME/bin is mode 700 right now? Really?
Yes. It's overkill, because that have to get past the dual firewalls first.
But that's what I do.
>
> Right. I didn't think so.
That is your choice.
>
> The problem with writing scripts is that they always outlive the original
> task, and the original user.
If I am going to make it public, I would vet it to make sure it meets
my standards. But if it's for my use, I solve the problems I need to solve.
>
> Hence, WRITE IT CORRECT. The differential cost isn't huge. It just takes
> diligence.
On the other hand, writing portable scripts that deal with files with
uncontrolled binary characters is not always possible.
Not all systems have the GNU find instaled on them.
You can go crazy making sure every script will run on every UN*X
system that is theoretically possible. If I take your attitude to the
extreme, shell scripts can become nightmares to maintain.
Maxwell Lol
> Maxwell,
>
> This time you should pay attention to the little man behind the curtain.
> He is definitely _not_ a humbug and knows of the wizardry of where he
> speaks.
I know exactly who he is. I've used perl for 15 years, and I listen to FLOSS.
>
> But you should definitely watch out for flying monkeys.
>
> And your little dog too.
Do your scripts run on every UN*X machine out there?
Maxwell Lol
> Well, except "\n" and space are printing characters, you just can't
> distinguish them readily from other whitespace in the terminal. And,
> unfortunately, file names with spaces are quite common on Windows or
> OS X, and if a linux box is the file server for those clients, it has to
> handle spaces in filenames well.
The only "clients" on my machines are ones I control 100% - because I
wrote them.
>
>> I NEVER allow non-printing characters in filenames on the systems I
>> use for myself, and where I am the only user.
>
> That's part of Randal's point--there are so many situations where you
> might think you're the only user, then something unexpected happens, you
> press a box into service, and you're no longer the only user, and you
> can't restrict filenames for one reason or another. It happens.
Excuse me. I *AM* the only user. I have 5 Linux machines at my house, and
I am the only human who uses them.
Marcel Bruinsma
> On the other hand, writing portable scripts that deal with files
> with uncontrolled binary characters is not always possible.
Could you give an example (file or path name) ?
--
printf -v email $(echo \ 155 141 162 143 145 154 142 162 165 151 \
156 163 155 141 100 171 141 150 157 157 056 143 157 155|tr \ \\\\)
# Live every life as if it were your last! #
Keith Keller
> Keith Keller <kkeller...@wombat.san-francisco.ca.us> writes:
>
>>> I NEVER allow non-printing characters in filenames on the systems I
>>> use for myself, and where I am the only user.
>>
>> That's part of Randal's point--there are so many situations where you
>> might think you're the only user, then something unexpected happens, you
>> press a box into service, and you're no longer the only user, and you
>> can't restrict filenames for one reason or another. It happens.
>
> Excuse me. I *AM* the only user. I have 5 Linux machines at my house, and
> I am the only human who uses them.
Okay, fine. Not all of us admin a box where we are the only user ever.
Maxwell Lol
> Am Dienstag, 29. September 2009 13:02, Maxwell Lol a �crit :
>
>> On the other hand, writing portable scripts that deal with files
>> with uncontrolled binary characters is not always possible.
>
> Could you give an example (file or path name) ?
Well, I should say optimum and portable can be a problem.
I'm thinking of the issue of dealing with nested directories and files
with non-printing characters, on a system that does not have GNU
find. Passing that into xargs would be a problem.
And if you don't use xargs, there is a performance penalty when
dealing with 100,000's of files. Some Solaris systems have a large
line length, and xargs was a vast improvement over the -exec
solution. I guess I prefer xargs over -exec when dealing with large
number of files.
Maxwell Lol
>> Excuse me. I *AM* the only user. I have 5 Linux machines at my house, and
>> I am the only human who uses them.
>
> Okay, fine. Not all of us admin a box where we are the only user ever.
I was an admin for a site with 1000 UN*X systems, and I maintained all
of the open source software (tis was before packaging) but the IT
department does that now. So I've been there.
Marcel Bruinsma
> Marcel Bruinsma <m...@nomail.afraid.org> writes:
>
>> Am Dienstag, 29. September 2009 13:02, Maxwell Lol a écrit :
>>
>>> On the other hand, writing portable scripts that deal with files
>>> with uncontrolled binary characters is not always possible.
>>
>> Could you give an example (file or path name) ?
>
> Well, I should say optimum and portable can be a problem.
>
> I'm thinking of the issue of dealing with nested directories and
> files with non-printing characters, on a system that does not
> have GNU find. Passing that into xargs would be a problem.
IMO the xargs described in IEEE Std 1003.1 is not fit for any
purpose at all. It's input must be preprocessed (encoded) to
stop xargs from performing horrific mutilations. ;-)
It's not a <newline> problem, xargs has problems with many
characters, including [:space:], <backslash> and quotes. The
thing must have been invented by someone very drunk, or
very insane, or both. :-/
GNU xargs escapes this madness by providing the -0 option.
> And if you don't use xargs, there is a performance penalty
> when dealing with 100,000's of files. Some Solaris systems
> have a large line length, and xargs was a vast improvement
> over the -exec solution. I guess I prefer xargs over -exec
> when dealing with large number of files.
'find [...] -print0|xargs -0 command' or
'find [...] -exec command {} +'
Looks like there won't be much between them.
In more complex cases, however, the ‘posix way’ is quite
inefficient compared to GNU.
GNU:
find [...] -print0 |
while IFS= read -rd$'\0' path
do
: process ${path}
done
or sometimes,
find [...] -print0 | awk -vRS=$'\0' '{ [...] }'
Posix:
find [...] -exec sh -c '
for path
do
: process ${path}
: might invoke awk for /each/ ${path}
done' sh {} +
When dealing with 1E5 files…
Geoff Clare
> 'find [...] -print0|xargs -0 command' or
> 'find [...] -exec command {} +'
> Looks like there won't be much between them.
>
> In more complex cases, however, the 'posix way' is quite
> inefficient compared to GNU.
>
> GNU:
> find [...] -print0 |
> while IFS= read -rd$'\0' path
> do
> : process ${path}
> done
>
> or sometimes,
>
> find [...] -print0 | awk -vRS=$'\0' '{ [...] }'
>
> Posix:
> find [...] -exec sh -c '
> for path
> do
> : process ${path}
> : might invoke awk for /each/ ${path}
> done' sh {} +
>
> When dealing with 1E5 files...
find [...] -exec awk '{ [...] }' {} +
--
Geoff Clare <net...@gclare.org.uk>