Executing script from current shell - HP-UX 2

[biggerV]

Being a relatively new to UNIX scripting, this particular problem is giving me problems. What I am trying to do is to 'modify' the UNIX cd command, so if a user fat fingers his input, e.g. c d /home/username the script called 'c' will recognize this and move the user to the directory he requested. The problem I am having is that that the script executes in a seperate shell and never moves the user to the correct directory, rahter he never leaves the current directory. If I execute the script with the . option it works correctly. So I guess my question is...Is there a way to execute the script from the current shell without using the . option? Thanks in advance.

 

[PHV]

Make it a function (or an alias) defined in the user's profile

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[biggerV]

An alias is not going to work, as the users would not be aware of this, and would get rejected regardless as the c d would only be recognized as 'c'. It is to be used when a user fat fingers their input. I really do now know how to make a function? Perhaps you could point me in the correct direction.

 

[PHV]

Can you please post your script ?

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[biggerV]

Its really quite simple, I think. Like I said in my first post, relatively new to UNIX scripting. I just can't figure out how to execute the script within the current shell. If I run the script with the .option '. c d /whateverdirectory' path it works fine.

#!/bin/sh
if [ $1 = "d" ] && [ -d $2 ] > /dev/null 2>&1
then
cd $2
fi

Thanks again.

 

[PHV]

At the end of the user's profile, add this code:
c() {
if [ $1 = "d" ] && [ -d $2 ] > /dev/null 2>&1
then
cd $2
fi
}

Another style to do the same thing:
c() {
[ "$1" = "d" -a -d "$2" ] && cd "$2"
}

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[chipperMDW]

Your logic for why an alias would not work makes no sense to me. However, a valid reason for it not working is that aliases don't accept arguments. Hence, a function should work. Here's how to make one in Bash:

function c
{
    if [ "$1" = "d" ]; then
        shift
        cd "$@"
    else
        command c
    fi
}

You might also want to set the cdspell shopt option in Bash. That'll let them misspell the directory name, too.


Are you going to do this for every command? People mistype more thngs than cd.

function l
{
    if [ "$1" = "s" ]; then
        shift
        ls "$@"
    elif [ "$1" = "d" ]; then
        shift
        ld "$@"
    elif [ "$1" = "n" ]; then
        shift
        ln "$@"
    else
        command l
    fi
}

In other words, is fixing users' typing mistakes important enough to focus on? If the c command otherwise runs an important, expensive command that they don't need to be running a lot, maybe you should consider moving that command out of the PATH instead of trying to avoid typos.

Otherwise, I hope you have a good reason for this. The effort spent fixing this is much more than the effort required for a user to type "C-p C-A C-f d <RET>" on the few occasions they mistype the cd command.


Then again, Bash does provide that builtin feature to ignore spelling mistakes in arguments to cd, which I've always thought was a bad idea, so maybe I'm missing something.

 

[biggerV]

Thanks to both of you.

Reasoning? Since when do bosses need reasons to request something?

 

[chipperMDW]

Some comments on your script:

Instead of redirecting syntax errors to [tt]/dev/null[/tt], do something about them.

In your case, I imagine the errors you were getting came when $1 and $2 were blank. Thus, surround them with quotes (like in my example). Then, when the arguments are blank, your condition correctly returns false instead of having a syntax error that you need to hide.


Your test for [tt][ -d "$2" ][/tt] is well-intentioned, but it takes some of the functionality away from cd.

For example, I commonly use [tt]cd[/tt] without arguments to return to my home directory, and [tt]cd -[/tt] to go back to the last directory I was in. Those would get rejected under your script.

It also makes it impossible to use command line options (like [tt]-P[/tt]) with the mistyped command.

Instead, you should just pass all the arguments to [tt]cd[/tt] as they were typed and let [tt]cd[/tt] decide whether they're valid or not, and then it can give appropriate errors if they aren't.


Finally, make your command do something reasonable when it decides not to cd. Otherwise, I can keept typing "c" over and over again and not get any indication that what I'm doing isn't working.

My example tries to run the [tt]c[/tt] command (the [tt]command[/tt] builtin causes it to ignore functions named [tt]c[/tt], thus avoiding a recursive loop). This way, if there is a [tt]c[/tt] command, I can still run it through your function. If not, then Bash will complain about not being able to find a [tt]c[/tt] command.

Letting Bash do the complaining keeps you from having to attempt to emulate Bash's error messages in order to keep consistent.


Also, a correction to my examples: replace

command c

with

shift
command c "$@"

and

command l

with

shift
command l "$@"

This allows you to pass arguments to the hypothetical [tt]c[/tt] and [tt]l[/tt] commands if they end up being run.

 

[chipperMDW]

Ah, yes, the boss. I suppose keeping your job is an acceptable reason for doing something like this.

 

[chipperMDW]

A correction to my corrections:

Get rid of the line [tt]shift[/tt] before both of the [tt]command x[/tt] lines... that'll just get rid of the first (possibly valid) argument.

Leave the other ones, though. Those are needed to get rid of the extra initial arguments that got typoed in.