Bash functions to redefine existing commands?

[jkp23]

From an earlier post on this board by mervTormel

Quote: bash aliases don't honor parameter passing (yet), so use a function:

So...heres my problem. I'm trying to create an alias to cd that does : cd; settitle.

settitle = an alias from another earlier thread that lets you change the title of the current shell window to the current working path.

problem: i dont think you can make a fucntion called cd that calls the real cd command as it goes into an infinite loop. I can't use an alias in bash for the above reason, so how do i go about doing this?

[aixccapt99]

From the bash man pages
(http://www.hmug.org/man/1/sh.html is a nice html version)

builtin shell-builtin [arguments] 
Execute  the  specified shell builtin, passing it arguments, 
and return its exit status.  This is useful when defining a 
function whose  name  is the same as a shell builtin, 
retaining the functionality of the builtin within the function. 
The cd builtin is commonly redefined  this way. 
The  return status is false if shell-builtin is not a shell 
builtin command.

So in your executable shell script, you should be able to write "builtin cd 'path' " where you want to run the original bash command.

Didn't test the whole thing, but at a bash prompt the command "builtin cd" works just as my (unmodified) cd command does.

[mervTormel]

well, it is considered bad form to mask real command names, so avoid using 'cd' as your function name.

secondly, it is recommended and good form to remove opaqueness from these function/alias definitions. i.e., spell it all out so that there is less confusion in the future when you examine your creation wondering what you were thinking.

$ alias foo="echo here\'s what alias foo does"

$ zcd () { builtin cd "$1"; pwd; foo; }

$ type zcd foo
zcd is a function
zcd () 
{ 
    builtin cd "$1";
    pwd;
    echo here\'s what alias foo does  # <- alias expanded
}
foo is aliased to `echo here\'s what alias foo does'

$ zcd tmp
/Users/brian/work/tmp
here's what alias foo does

[aixccapt99]

Merv's points are well taken. To provide a little counterpoint, just for the sake of discussion:

It is common to alias commands to themselves, with your preferred options -- for example, alias rm to rm -i for safety (forces rm to ask about each file). Another example, I have

alias du="du -h -d 1"

in my .bashrc so that du output is more useful to me. (du actually accepts a path argument, which does get passed through the alias... )

In this case, it seems to me as if the desired functionality is a close extension of the standard cd command -- it's the usual cd, plus the no-consequences effect of setting the window title informationally. Sort of like setting a nice option (that isn't actually there, granted). Though it borders on too much modification, I can see wanting this to be literally named cd -- especially if the replacement script is designed to fail gracefully when the new cd might be executed by a non-terminal program (for example, in a StartupItem).

I do like the idea of echoing out a reminder that standard cd has been overridden, maybe with info about how to get it back.

[hayne]

Quote: Originally posted by aixccapt99 It is common to alias commands to themselves, with your preferred options -- for example, alias rm to rm -i for safety (forces rm to ask about each file).

It is also common for people to cross the street without looking - that doesn't mean it is a good idea! The huge problem with your particular 'rm' example is that you would get used to having that "-i" option in place and then one time you are working on some other machine and you are a bit too careless with your 'rm' (since you expect to be asked about each file) and important files get lost.

[mervTormel]

hayne's example is a good one.

and another thing: you may lose the functionality of the generic command when you need it.

do you know how to turn off alias expansion? in bash, prepend a backslash to the alias. i.e., if 'ls' is aliased to some other command, '\ls' will run the real 'ls' command.

and yet still another further different thing: i've seen users do this command masking and the next week can't figure out why another usage of a masked command won't work. the opaqueness is subtle and often difficult to diagnose without previous experience experiencing it.

[jkp23]

Very intersting points, and after due consideration, I'd say im inclined to think that this kind of stuff isnt the best idea. One situation I can se where it might cause problems, besides all the ones mentioned, is building software.

I've already had my builds fail in the past simply by modifying some ENV variables, that the build scripts weren't expecting to see modified. What on earth happens when your build is trying to rm some temp files and it is asked to confirm each one? Or something of the like anyhow.

Thanks for the thoughts, I think for the sake of not getting in to bad habits I wont bother.

[vonleigh]

Do bother, just name it something different. I have tons of aliases[1], just that they're all named differently from the command. Notice that mt called his replacement command zcd. In your case since you want settitle, why not scd, or wcd (for window) or whatever helps you remember. Just do a which 'your-new-name' to see if it already exists, if not, go for it.


v


[1] I guess a downside is you do get dependent on them, i use ll constantly (it's ls -la $* | less -e) for example.