|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Interactive rm
|
In the message dated: Wed, 01 Feb 2006 14:44:57 EST,
The pithy ruminations from Art Alexion on
<Re: [PLUG] Interactive rm> were:
=> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
=> --------------enig82C6FEFB5B54D8F5D42F78F1
=> Content-Type: text/plain; charset=ISO-8859-1
=> Content-Transfer-Encoding: 7bit
=>
=> bergman@merctech.com wrote:
=>
=> >the original posted requested a slightly
=> >different behavior, as in:
=> > if there are multiple arguments to rm, then run rm interactively
=> > if there is a single argument to rm, then run rm non-interactively
=> >
=> >This is not as trivial as it appears. While it's easy to count the number of
=> >arguments and call "rm -i" if there's more than one argument, this doesn't deal
=> >correctly with arguments that are options, not the targets of the rm command.
=> >In addition, rm is sensitive to the order of arguments, and it's easy to get
=> >unexpected results when combining "-f" and "-i". I'm also skipping over the
=> >issues with targets that have embedded whitespace in their names...
=> >
=> >=> > How can I restore rm's default behavior so that "rm *" requires
=> >=> > confirmation, but "rm specified_file" does not?
=> >
=> >Here's a bash shell function that will do what you want. This fragment of code
=> >can be put in your ~/.bashrc file. Note that the function, as named, will work
=> >when called as "myrm". You can change this to "rm" and therefore hide how "rm"
=> >really behaves.
=> >
=> >
=> Thank you Mark. That does the trick. A couple of test yield the
=> following, though:
=>
=> * it seems, as written, it is called with 'saferm', not 'myrm', right?
Right. My typo...I changed the name during "development".
=> * though it doesn't treat options as file arguments, it does not
=> pass the options to rm, so 'saferm -f *' still runs rm as 'rm -i *'
Um, it _does_ pass the options to rm.
Nope. If multiple targets are present, the function calls:
rm $all-options -i $targets
this is because the "-f" and "-i" options are mutually exclusive, and whichever
appears last on the command line "wins". The original program specification
didn't say anything about using "-f", so the shell function puts "-i" last in
the list of options, thus overriding "-f" if it's present.
Submit a change request to the development team, wait for managerial approval
and budgetary allocation. Depending on available resources and priority, and
the schedule of the test team, you should have the beta version by Q3 2006.
Once it's been approved by the User Acceptance Group, and the technical writer
updates the documentation, it can be released. :)
Or, you can edit the shell function, and change:
/bin/rm $options -i $targets
to
/bin/rm -i $options $targets
=> * I wanted to rename it just 'rm', but then presumed that the 'rm
=> wildcard' stuff in some of my scripts would start to require
=> confirmation which I could not force with 'rm -f wildcard'
See above.
=> * I knew it would be tough to change my habit of just typing rm to
=> typing saferm (and the evil I am trying to avoid is habit driven),
=> so I renamed it 'del' as in DOS del (I often type rm in a win
=> command shell as it is) which is just regaining an old habit.
=> * a weird observation. I have three shells open. I did my
=> experiments with one of the shells only, i.e. I only ran the
=> command 'source ~/.bashrc' in one of the shells. In that shell, I
=> ran the function after renaming it 'rm'. After I found out that
=> 'rm -f *.flub' no longer overrode the -i option, I changed the
=> name to del and ran 'source ~/.bashrc' again. But in that shell,
=> rm still asks for confirmation, even though del works, too. In
This is because the initial shell function (named rm) is still present, in
addition to the "del" function.
=> the other shells, I only ran the source command only after I was
=> done editing, and rm works as it does by default.
Yes. This is because those shells only have the single "del" function.
=> * You are right that it doesn't work with files with embedded spaces.
:)
=>
=> Thanks, again. I really appreciate the help.
Sure. Not a problem.
Mark
=>
[SNIP!]
=> _______________________________________
=> Art Alexion
=> Arthur S. Alexion LLC
=>
=> PGP fingerprint: 52A4 B10C AA73 096F A661 92D2 3B65 8EAC ACC5 BA7A
=> The attachment -- signature.asc -- is my electronic signature; no need for alarm.
=> Info @ http://mysite.verizon.net/art.alexion/encryption/signature.asc.what.html
=>
=> Key for signed PDFs available at
=> http://mysite.verizon.net/art.alexion/encryption/ArthurSAlexion.p7c
=> The validation string is TTJY-ZILJ-BJJG.
=> ________________________________________
=>
=>
=> --------------enig82C6FEFB5B54D8F5D42F78F1
=> Content-Type: application/pgp-signature; name="signature.asc"
=> Content-Description: OpenPGP digital signature
=> Content-Disposition: attachment; filename="signature.asc"
=>
=> -----BEGIN PGP SIGNATURE-----
=> Version: GnuPG v1.4.1 (GNU/Linux)
=> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
=>
=> iQCVAwUBQ+EPv0LG/oYII0YuAQJ68AP9GLjPTjxIImVLrZ7ID+ByozGRfp8nEq3Q
=> icJ0O7dNTASW8tCF3OGzhuQbrLwj/H4MLLDZ1VlfiAl/FN61P9Q1lXL11kxNnCbC
=> IkRGVpuFdxexQLD3kmxgpG7r/3ZhwHecs1BjJGZpCHYRvCJ9kZl+tm5vZEcpKBTs
=> BvdhTKsZ9P0=
=> =PkDD
=> -----END PGP SIGNATURE-----
=>
=> --------------enig82C6FEFB5B54D8F5D42F78F1--
=>
----
Mark Bergman
bergman@merctech.com
Seeking a Unix/Linux sysadmin position local to Philadelphia or via telecommuting
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|