Not really a programming question, but more scripting. (Depending on whether you think there's a difference.)

I've been doing some of the 'man', 'google', 'search LQ' routine for this very basic concept but I'm still not sure I'm really getting it. (I have a lot of questions in Linux like this.) What are the characteristics, limitations, advantages, of aliases, functions, and even full scripts?

What I get is that an alias can't handle variables.
alias seek='ps aux | grep -i $1'
is meaningless, right? You still have to specify the $1 and, from the aliases point of view, it's {ps aux | grep -i *cough*} and *then* $1 is interpreted outside the alias? So
alias seek='ps aux | grep -i'
is really the way to write it.

And if I wish to re-use 'seek' in a shell script, I can't. If it's a function, I can.

Then there's scripts. Scripts default to spawning a subshell. Functions run in the current instance. But I can source a script ('. myscript') and it'll run in the current instance.

My main question, I guess, is from a bash config/environment point of view. Not so much using functions within scripts but setting the environment. I've got some aliases and some functions in ~/.bash_profile|~/.bashrc. And some scripts that are really freaking simple but I just spontaneously wrote 'em that way - as separate files with a shebang. But why use aliases at all? Or functions? I just don't get the distinctions, in that Linux is like silly putty. You can twist anything into anything so why use any particular thing over another?

vim ll
#!/bin/bash
ls -l

vim ~/.bash_profile
function ll () {
ls -l
}

vim ~/.bashrc
alias ll='ls -l'

What's the difference? *shrug* Same goes for the files. My ~/.bashrc is actually just a symlink. I can see how it might be useful to distinguish between login and non-login shells but I really don't care. How different are these? Why are aliases supposedly supposed to go in ~/.bashrc and everything else in ~/.bash_profile?

And all the docs I've seen discuss neat tricks or general rules, but they don't really do comparisons much or explain the whys and wherefores. (I think I've heard that described as a mental difference in OSes - Windows is what, Linux is how, BSD is why or something like that.)

Anyway - if knowledgeable programming folks wanted to have a generalized discussion about this and enlighten an eternal newbie, that'd be great.

You can declare functions in your login script. They then become available to child processes. I don't think doing that is a good idea because when someone else tries to use your script or you have a disk problem and restore an older version of your login - the function is gone. If the fucntion is in a working script, even an older version of the script will work.

Aliases are essentially just text abbreviations. Basically all an alias does is that when the shell encounters a command to execute and it's an alias, it basically substitutes the text for that alias into where the alias is, and THEN evaluates everything else. That's why they can't take arguments.

Thanks, Strike - so basically, I should look at aliases like a fancy form of tab-completion - they don't have anything to do with scripting at all, and I can just set them aside? If it's something I just want while I'm typing on the command line, an alias is fine, but they aren't good for anything else and, if I want it in other contexts, I need it to take some other form? I mean, aliases can perform some reasonably full actions - like
but they can't do 'cp $1 $2' so they're only good for a specific objective. (And I guess the shell does tilde expansion within aliases, but not variable expansion? The issue isn't expansion as such, but what kind of expansion.)

So that leaves functions and outright scripts. Thanks to you, too, jim. By 'login script', did you mean ~/.bash_profile or ~/.bash_login - or something special to be sourced? But I do have some functions in ~/.bash_profile. However, they're not necessarily anything I reuse in scripts - more like things that just stretched the capacity of aliases. But you're saying that functions are primarily intended to be reusable code segments and not a way to cheat around the limits of aliases? So if I have something I don't intend to reuse I *can* put them in my environment but that either isn't the real purpose or is something for private scripts, only. If I was doing serious scripting, they'd need to be portable, so should reference functions contained in the scripts thmeselves?

For instance, sometimes I want to know what package something came out of so
does that for me. An alias wouldn't cut it, because it has to be variable but it's not worth an independent script and isn't anything I reuse in any other scripts. So that's appropriate?

And basically, if it's for my personal use, it's just a matter of degree? If it's more than a simple line I can throw in ~/.bash_profile, it might as well be a script? (I mean, obviously if I'm trying to write a non-trivial script it's not a case of 'might as well be' but I mean for the borderline silly stuff.)

I want to make sure I'm not missing any gotchas, either. You lose aliases in subshells and lose environment functions in other environments but a well-written, self-contained (as much as scripts can be), compatible /bin/sh script will run most anywhere and so on. And the functions contained within it are the same way, naturally, as long as they are contained within it.

Right? Maybe?