top | item 16718010

(no title)

racer-v | 8 years ago

Why do you think it's good to put a long command in a script, but bad to make it an alias? It sounds like you think shell dotfiles can't be managed across machines just like script files.

discuss

order

_Marak_|8 years ago

That isn't exactly what I wrote, but I'll still try to answer your question.

An alias is only going to be available to the current shell and it's going to be stored in memory. A script is going to be accessible to the entire system and stored on disk.

In the majority of my use-cases I require shipping software to production systems and my scripts are used to manage production services. The last thing I want to do is having to manage aliases on multiple systems ( some of which I do not own ).

racer-v|8 years ago

To me the difference between a script and an alias is too trivial to quibble over. I'm fine putting all of my aliases into one-line scripts, if that would really make them easier to manage across systems.

My basic philosophical disagreement is with the idea of avoiding interactive command shortcuts. This essentially limits you to only using command line features you can memorize, or be willing to look them up every single time. There are too many commands, with totally inconsistent argument styles, for this to be practical.

The result is that you're only going to use a small subset of the command line's power if you limit yourself in this way.

RANT: Yes, I agree alias ll="ls -l" is a crutch. But why does 'sort' use -t for separator and -f for field, while 'cut' uses -d and -k? The famously composable Unix tools really aren't very consistent. Radically improved tab completion and documentation (vs man pages and Info) might be a start, but in the end you have to evolve new syntax.

lallysingh|8 years ago

Unsolicited opinion on this: she'll scripts are great for adding documentation to commands. I've got a lot of 2-5 line scripts that just remember the right commands for me.

Aliases I only use as direct abbreviations of the underlying command.