Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Fri, Jun 24, 2022 at 07:02:35AM +, Andrew M.A. Cater wrote: Train your brain and your fingers to move the rf to the end of the command so that you _have_ to check what filename you are typing as you type it. I set a shell alias alias rm='echo use trash instead' This was enough to train me out of typing "rm" in most situations and instead use 'trash': https://tracker.debian.org/pkg/trash-cli Another advantage of trash-cli, as well as the safety measure, is 'trashing' large trees is much faster than deleting them. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Sat, Jun 25, 2022 at 09:45:58AM -0400, Greg Wooledge wrote: > On Fri, Jun 24, 2022 at 07:42:25PM -1000, Joel Roth wrote: > > I list the files first: > > > > ls some-pattern > > > > then add a pipe to rm: > > > > ls some-pattern | rm > > > > or > > > > ls some-pattern | rm -rf > > Those commands do not work. rm does not read a list of files from stdin. > > Even if you were to add xargs, those commands still would not work in > all cases. They would only work in the simplest cases, where none of > the filenames contain whitespace, single-quote characters, or double-quote > characters. > > That's because xargs does not split its input on newlines. It splits > its input on "quoted words". Like this: > > unicorn:~$ echo 'a list of "quoted words"' | xargs printf '<%s>\n' > > > > > > Any unbalanced single or double quote will cause an error: > > unicorn:~$ echo "I don't know.mp3" | xargs printf '<%s>\n' > xargs: unmatched single quote; by default quotes are special to xargs unless > you use the -0 option > > > And even if xargs *did* have some option to split its input only on > newlines, a filename that *contains* a newline would still break it. > > Finally, ls does not always reproduce filenames exactly. There are > some systems (I'm not sure about all versions of Debian, but definitely > some Unix systems) where certain characters will be printed as > question marks by ls. That means any file containing one of those > characters would make the ls|xargs rm construct fail. > > If you want to use ls as a preview for what will be removed, that's > perfectly fine. You just can't use "up arrow | xargs rm" as your > follow-up command. Instead, use "up arrow" and then use command editing > to replace the ls with rm. I was actually using 'xargs rm' in an alias. Thanks for pointing out the limitations. -- Joel Roth
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Fri, Jun 24, 2022 at 07:42:25PM -1000, Joel Roth wrote: > I list the files first: > > ls some-pattern > > then add a pipe to rm: > > ls some-pattern | rm > > or > > ls some-pattern | rm -rf Those commands do not work. rm does not read a list of files from stdin. Even if you were to add xargs, those commands still would not work in all cases. They would only work in the simplest cases, where none of the filenames contain whitespace, single-quote characters, or double-quote characters. That's because xargs does not split its input on newlines. It splits its input on "quoted words". Like this: unicorn:~$ echo 'a list of "quoted words"' | xargs printf '<%s>\n' Any unbalanced single or double quote will cause an error: unicorn:~$ echo "I don't know.mp3" | xargs printf '<%s>\n' xargs: unmatched single quote; by default quotes are special to xargs unless you use the -0 option And even if xargs *did* have some option to split its input only on newlines, a filename that *contains* a newline would still break it. Finally, ls does not always reproduce filenames exactly. There are some systems (I'm not sure about all versions of Debian, but definitely some Unix systems) where certain characters will be printed as question marks by ls. That means any file containing one of those characters would make the ls|xargs rm construct fail. If you want to use ls as a preview for what will be removed, that's perfectly fine. You just can't use "up arrow | xargs rm" as your follow-up command. Instead, use "up arrow" and then use command editing to replace the ls with rm.
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Fri, Jun 24, 2022 at 07:02:35AM +, Andrew M.A. Cater wrote: > There are a couple of useful habits to get into when removing things: > > There's an > > rm -i > Use the pwd command to check where you are in the > filesystem. (It may be short for "print working > directory"). > If you are deleting one file - change to the directory it is in, check that > it exists there first with the > > ls -al [filename] > > command. Since the file is in the current directory,you can use the > > rm ./[filename] > > [That's a period and a forward slash - limiting you to a file in the current > directory] > > Try and avoid using rm -rf and forced removal. The one exception is that > you have to remove a non-empty directory with -rf. If you first try -r > and it fails, that's a clue that you are actually about to delete a > directory. > > Again, if it's a single directory, change directories to the directory > that it is in and use the ./ The last suggestion, and it's the simplest: > > rm [filename] -rf ... > If you need to be doubly sure rm [filename] -irf will put in the interactive > prompt again. > > Some of this is learnt the hard way from administering one machine that > other people relied on :) All good suggestions, along with making backups. I list the files first: ls some-pattern then add a pipe to rm: ls some-pattern | rm or ls some-pattern | rm -rf I know the OP said they weren't asking advice, but I can't help putting in my two bits :-) cheers, > With every good wish, as ever, > -- Joel Roth
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Fri 24 Jun 2022 at 08:48:05 (-0400), rhkra...@gmail.com wrote: > On Friday, June 24, 2022 03:02:35 AM Andrew M.A. Cater wrote: > > The last suggestion, and it's the simplest: > > > > rm [filename] -rf > > > > Train your brain and your fingers to move the rf to the end of the command > > so that you _have_ to check what filename you are typing as you type it. > > > > If you need to be doubly sure rm [filename] -irf will put in the > > interactive prompt again. > > I like all these suggestions, as well as Thomas' addition (although I'm not > sure I'm ambitious enough to go back and edit the comand buffer). Ambitious? Line editing and command history are two of the most useful things about working at the command line. And I recommend that you train your fingers to type rm -i (similarly for cp and mv) rather than relying on the system to add -i for you. You can thereby avoid a lot of harm -i to your system (oops). For mass deletions, I would: Use rm -i … and check that the filenames being reflected are from the tree you expected. Recall the command, then first add a space at the start of the line, and next, remove the -i. The space prevents the potent version of the command (without the -i) being added to your history when you press Return.¹ > I do something slightly different than what Andrew suggests, I put the > filespec > on the blank command line, and then go back and insert the rm -rf before the > filespec. Slightly different, but I use this with other potent commands, like dd: Start the command line with # space, followed by the command and its arguments. Study what you have written, then delete the # (but leave the space: you don't want such potent commands left in your history). ¹ You don't want to be able to later recall this command accidentally, in a different context. So put export HISTCONTROL=ignoreboth into your .bashrc file, preventing lines starting with a space from being added to your command history. Cheers, David.
Re: Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Friday, June 24, 2022 03:02:35 AM Andrew M.A. Cater wrote: > The last suggestion, and it's the simplest: > > rm [filename] -rf > > Train your brain and your fingers to move the rf to the end of the command > so that you _have_ to check what filename you are typing as you type it. > > If you need to be doubly sure rm [filename] -irf will put in the > interactive prompt again. I like all these suggestions, as well as Thomas' addition (although I'm not sure I'm ambitious enough to go back and edit the comand buffer). I do something slightly different than what Andrew suggests, I put the filespec on the blank command line, and then go back and insert the rm -rf before the filespec. My approach might be slightly safer -- there is less possibility of deleting one (or more than one) (wrong) file by fat fingering something (hitting enter) (I'm good at that :-( before getting the filespec correct. For example, suppose you have files test and test1, and you want to delete test1 but not test -- if you accidentally hit enter after typing test but before typing the 1 you will be disappointed. -- If you reply: snip, snip, and snip again; leave attributions; avoid top posting. A picture is worth a thousand words -- divide by 10 for each minute of video (or audio) or create a transcript and edit it to 10% of the original. (Oxford comma included at no charge.)
Suggestions for rm [WAS: Re: Feature request: install package by passing URL to apt-get]
On Thu, Jun 23, 2022 at 04:27:28PM -0400, Bijan Soleymani wrote: > On 6/23/2022 12:03 PM, Person the human wrote: > > The easier something is to do, the more harmless people will think it > > is, so you're right. Thanks. > > rm wrongfile > > how do I undelete? > > better put deleted files in the "recycling box" and prompt users on every > deletion by default > > rm -rf / > > oops! > > sigh... > > Bijan > > For the general "I rm'd something critical" - there is no absolute solution. Root/superuser privileges can do almost anything and everyone makes that mistake once. There are a couple of useful habits to get into when removing things: There's an rm -i switch to the rm command. This makes the removal interactive - you get an "Are you sure [Y/N]" warning for each file. This is useful for a single critical file, less useful when you're removing a hundred logfiles. On a Red Hat-derived system, this is often aliased to rm by default. That's a great idea - until you move to a system where rm means rm immediately. Use the pwd command to check where you are in the filesystem. (It may be short for "print working directory"). If you are deleting one file - change to the directory it is in, check that it exists there first with the ls -al [filename] command. Since the file is in the current directory,you can use the rm ./[filename] [That's a period and a forward slash - limiting you to a file in the current directory] Try and avoid using rm -rf and forced removal. The one exception is that you have to remove a non-empty directory with -rf. If you first try -r and it fails, that's a clue that you are actually about to delete a directory. Again, if it's a single directory, change directories to the directory that it is in and use the ./ The last suggestion, and it's the simplest: rm [filename] -rf Train your brain and your fingers to move the rf to the end of the command so that you _have_ to check what filename you are typing as you type it. If you need to be doubly sure rm [filename] -irf will put in the interactive prompt again. Some of this is learnt the hard way from administering one machine that other people relied on :) With every good wish, as ever,
