01-12-2011 10:23 PM
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:
Solved! Go to Solution.
01-13-2011 04:45 AM
> [...] I may be thinking inside the box.
Inside the wrong box?
> [...] Perhaps there's something simple I'm
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
01-13-2011 08:53 AM
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?
01-13-2011 06:36 PM
> 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.).
01-13-2011 08:24 PM
> 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
> [...] '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.
01-13-2011 11:01 PM
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.
01-14-2011 09:34 AM
>Porting Centre then you now have the
>'depothelper' to collect and install all
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
>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?
01-18-2011 02:24 PM
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.