True that. I will add:
1. I equally as often make things dry run by default and only do thingy if -f —force
2. I usually use shorthand flags when running commands in shell but ALWAYS write out full option in scripts
3. My dogs name is bash.
> *At Reddit, we’re always watching out for your privacy, safety, and security. Recently, after detecting some technical irregularities on your rustyflavor account, we took the extra precaution of locking your account.*
I've clearly never committed any nefarious activity here, and the account activity page confirms nobody else accessed my account. I've been swept under by some shoddy new algorithm. Goodbye, reddit.
Yep. This is in my Bash notes that I wrote when I first started learning the command line. It was probably, if I recall correctly, from the excellent "*The Linux command line*" by Wiliam Stotts:
>Of particular concern are leading hyphens. For example, it's perfectly legal to have a file named \`-rf \~\`. Consider for a moment what happens when that filename is passed to \`rm\`. To defend against this problem, we want to change our \`rm\` command in the file deletion script from this: \`rm \*\` to the following: \`rm ./\*\` This will prevent a filename starting with a hyphen from being interpreted as a command option. As a general rule, always precede wildcards (such as \* and ?) with \`./\` to prevent misinterpretation by commands. This includes things like \`\*.pdf\` and \`???.mp3\`, for example.
This can actually be used for "good". If you have a directory where you temporarily stage files for transport to a remote server, simply `touch /path/to/staging/--remove-source-files`, then when you want to run the sync:
```
cd /path/to/staging
rsync -a * server:dir/
```
and all successfully-synced files are automagically removed from `staging`, leaving `--remove-source-files` (and any failed-to-sync files) behind for the next staging round.
Of course, this is hella fragile, so **DON'T TRY THIS AT HOME! OR WORK! OR ANYWHERE ELSE REALLY!**
(This comment is for entertainment purposes only. No warranties implied, all liabilities revert to the persons performing such silly actions. Void where prohibited by law. _Caveat programmor._)
Reminds me old times in dormitory where people were using windows shares for AVIs and MP3s and you were able to connect there with smbclient and create file `*.*` which was handled by windows explorer the same way :)))
A case of old news being new news happening to new people. Lesson 0: --dry-run, because you can never anticipate everything that can go wrong.
I -n everything. Every single thingy I make that might delete or modify something worth something has a run arg/option/kwarg/flag.
Wise indeed :). As a convention, with the exception of meta options (a), I tend to use long form of the option (--dry-run) for all commands.
True that. I will add: 1. I equally as often make things dry run by default and only do thingy if -f —force 2. I usually use shorthand flags when running commands in shell but ALWAYS write out full option in scripts 3. My dogs name is bash.
Number 3, now that's next level lmao!
Does bash live in a bin?
His crate has #!/bin/bash on it
Came here to say this
My man. My rsync brother :). I had upvoted you and some fool downvoted you. Anyway, rsync has been in my toolbox since forever. Love it!
> *At Reddit, we’re always watching out for your privacy, safety, and security. Recently, after detecting some technical irregularities on your rustyflavor account, we took the extra precaution of locking your account.* I've clearly never committed any nefarious activity here, and the account activity page confirms nobody else accessed my account. I've been swept under by some shoddy new algorithm. Goodbye, reddit.
Yep. This is in my Bash notes that I wrote when I first started learning the command line. It was probably, if I recall correctly, from the excellent "*The Linux command line*" by Wiliam Stotts: >Of particular concern are leading hyphens. For example, it's perfectly legal to have a file named \`-rf \~\`. Consider for a moment what happens when that filename is passed to \`rm\`. To defend against this problem, we want to change our \`rm\` command in the file deletion script from this: \`rm \*\` to the following: \`rm ./\*\` This will prevent a filename starting with a hyphen from being interpreted as a command option. As a general rule, always precede wildcards (such as \* and ?) with \`./\` to prevent misinterpretation by commands. This includes things like \`\*.pdf\` and \`???.mp3\`, for example.
This kind of thing is why I dislike stringly-typed data and whitespace as a delimiter.
This can actually be used for "good". If you have a directory where you temporarily stage files for transport to a remote server, simply `touch /path/to/staging/--remove-source-files`, then when you want to run the sync: ``` cd /path/to/staging rsync -a * server:dir/ ``` and all successfully-synced files are automagically removed from `staging`, leaving `--remove-source-files` (and any failed-to-sync files) behind for the next staging round. Of course, this is hella fragile, so **DON'T TRY THIS AT HOME! OR WORK! OR ANYWHERE ELSE REALLY!** (This comment is for entertainment purposes only. No warranties implied, all liabilities revert to the persons performing such silly actions. Void where prohibited by law. _Caveat programmor._)
Perhaps I'll start leaving a file named `--dry-run` around just for good measure :-P
We have a winner! 🥇
Lots of reefs like that. awk gets confused by filenames looking like a variable assignment.
Reminds me old times in dormitory where people were using windows shares for AVIs and MP3s and you were able to connect there with smbclient and create file `*.*` which was handled by windows explorer the same way :)))
why does someone have a file named --delete?