shell - pre-exec/post-exec command

[Michael Morris]

Hello all,

In an attempt to avoid installing bash, I'm trying to find if there is a way in HPUX native shells (posix, ksh, csh[last resort]) to always execute a command BEFORE the command typed at the prompt on the commandline.

With bash, I can use the "trap" builtin:
"If a sigspec is DEBUG, the command arg is executed before every simple command..." -bash(1)

However, with sh-posix, the trap executes after the command runs:
"If sig is DEBUG, then arg is executed after each command." -sh-posix(1)

In addition to this, I would also appreciate a solution for $PROMPT_COMMAND. I believe this can, potentially, be accomplished through the aforementioned trap or using command-substitution within the $PS1 variable. Though for my purposes, I would need to be capable of setting variables within current shell and not sub-shells.

Why on earth do I need this?!?! I want to display the running command in my title bar :)(actually it's for screen/tmux window names)

I've been looking at this for a while, and I feel I may be thinking inside the box. Any outside assistance is appreciated. Perhaps there's something simple I'm overlooking.

An example of what I'm talking about:
http://www.twistedmatrix.com/users/glyph/preexec.bash.txt

Thanks,

Mike

[Steven Schweda]

> In an attempt to avoid installing bash,
> [..]

> [...] I may be thinking inside the box.

Inside the wrong box?

> [...] Perhaps there's something simple I'm
> overlooking.

Like using "bash"?

To me, it seems that a job like this would be
best handled by the shell, although I was
unaware that even "bash" could do it. If
"bash" _can_ do it, then I'd vote for using
"bash". (Which I generally do, but for other
reasons.) _Why_ do you shun the obvious
solution?

[Michael Morris]

HA! Thanks for the reply. I figured I'd get a reply similar to yours. Yes, from what I can see, bash (or similarly more advanced shell) is the solution.

Just trying to avoid installing another shell and it's dependencies, that only I will use and cause yet another package that I would have to maintain up to date and patch outside of a standard patch bundle.

I try to avoid installing software that cannot be maintained by standard patch bundles unless there's an absolute business reason to do so. This isn't a business requirement; it's a personal one. If I were to go this route, bash would need to be installed, and maintained, on all my systems.

If I can do it natively, why not?

Anyone else have any other ideas?

[James R. Ferguson · Accepted solution]

Hi MIke:

> Just trying to avoid installing another shell and it's dependencies, that only I will use and cause yet another package that I would have to maintain up to date and patch outside of a standard patch bundle.

But, I'm in agreement with Steven: if the bash shell fulfills your need, why re-invent the wheel? I too, was unaware of the ability to "pre-process".

As for having to "...maintain up to date and patch outside of a standard patch bundle", this shouldn't be a big issue if what you gain (albeit for personal use) is something you can't live without.

If you fetch the 'bash' shell from the HP-UX Porting Centre then you now have the 'depothelper' to collect and install all associated dependencies. I don't think that that this differs significantly from maintaining any other non-HP-provided add-on product (e.g. 'lsof', 'tusc', etc.).

Regards!

...JRF...

[Steven Schweda]

> Just trying to avoid installing another
> shell and it's dependencies, that only I

That's "its dependencies".

> will use and cause yet another package that
> I would have to maintain up to date and
> patch outside of a standard patch bundle.

Perhaps you can find more users for it.

I can't remember any case where even a pretty
old "bash" actually _needed_ to be updated or
patched. I typically try to remember to
refresh my "bash" with a newer one when I do
an OS upgrade or a fresh installation
somewhere. I can't remember it ever breaking
spontaneously.


> [...] 'depothelper' [...]

I tend to build my stuff from the sources, to
reduce mismatches (and mysteries) with the
build-time and/or run-time infrastructure,
but I'll admit that keeping enough of the GNU
stuff in shape can be a project of its own.

[Dennis Handly]

>I want to display the running command in my title bar

I have some shell functions that display the machine and CWD. I'm not sure how you would get the current command in a real shell. I'm not sure if $_ is the last command or the last parm on that command. (It seems it is the latter.)

And this won't work since that is only changed, AFTER the command is finished.

[Michael Morris]

>If you fetch the 'bash' shell from the HP-UX
>Porting Centre then you now have the
>'depothelper' to collect and install all
>associated dependencies.

Thanks James, I didn't know about depothelper. Perhaps it will help. I'll check it out!

>That's "its dependencies".

I'm usually a stickler for that as well. Thanks for the grammar reminder.
Hmm... I'll blame it on the recent influx of bad weather in my area. ;)


>I have some shell functions that display the
>machine and CWD. I'm not sure how you would
>get the current command in a real shell. I'm
>not sure if $_ is the last command or the
>last parm on that command. (It seems it is
>the latter.)
>
>And this won't work since that is only >changed, AFTER the command is finished.

I am using the mcd function/alias to change the CWD in my prompt. And I'm currently using $PS1 to change my window title within GNU screen. I'm trying to switch to tmux which handles the window titling a little different with regards to the running command.

If bash on HPUX works like bash on Linux (i'm assuming it would), you can use "trap 'function_that_changes_title' DEBUG" in your .bashrc and the trap will occur BEFORE the command on the commandline runs. It also provides $PROMPT_COMMAND instead of just $PS1 which might work better for this task. With those two abilities, you can change the title before and after the command runs. So you would be able to change title to the running command, have the command execute, and after it's done, change title back to the hostname (or whatever you wanted it to be).

So far, I'm seeing what I guess I expected to see for replies. A lot of, "just go with bash". I appreciate that, as it helps affirm what I've researched. Thanks to all who have replied!

Anyone else have any other ideas?

[Michael Morris]

Thank you to everyone who replied. I'll heed your advice and run with bash.

It seems to be working great for me so far. In case you're interested, I've attached a file with the code I'm currently using in my ~/.profile. I pulled the core pieces from the link in the original post.

When not running under GNU Screen or tmux, it may show the escape codes to the terminal. However, it looks great when using either of those two applications.

Thanks again for all your insight.

[Michael Morris]

Solution was: Install bash.
Closing thread.