From: "Matt Wozniski" <godlygeek@gmail.com>
To: zsh-workers@sunsite.dk, zsh-users@sunsite.dk
Subject: Re: "jobs" command within substitution
Date: Thu, 8 Mar 2007 16:19:52 -0500 [thread overview]
Message-ID: <17393e3e0703081319r7a77aaf0w24f856abc5c7ea5c@mail.gmail.com> (raw)
In-Reply-To: <45F070A9.5060502@cowan.name>
On 3/8/07, Micah Cowan wrote:
> Matt Wozniski wrote:
> > On 3/8/07, Micah Cowan wrote:
> >> Hello, all. This is my first post to this group.
> >>
> >> I scoured the manpages and list archives, but could not find the answer
> >> I seek.
> >>
> >> My question, in a nutshell, is: How can I effectively use the "jobs"
> >> builtin command in producing the interactive prompt?
> >
> > Rather than trying to parse the output of the 'jobs' command, you
> > might find yourself better suited by manipulating the variables
> > $jobdirs, $jobstates, and $jobtexts. You correctly identified the
> > problem that you're hitting - $(jobs) is running in a subshell that
> > doesn't have any jobs in its job table. I agree, however, that (jobs)
> > should also be blank, since it's also running in a subshell. If,
> > however, you're dead-set on parsing the output of 'jobs', you could
> > use a syntax like 'jobs > >(read jobtext; echo $jobtext)', which is a
> > clever way to run jobs in the current shell and do the parsing in a
> > subshell via process substitution.
>
> Myself, I'd prefer to see both subshells produce the same output as the
> "current shell", as bash, pdksh and ksh do. However, dash goes the other
> way and makes ( jobs ) emit nothing (for all its claims of being a POSIX
> shell, though, dash is fairly broken in some respects, such as broken
> arithmetic expansion and lack of a line-editor [which POSIX requires]).
> I'd be interested in seeing what the OpenGroup committee has to say
> about it, since the standard is far from clear on the subject.
>
> I was not familiar with the variables you mention above. However, I'm
> not sure they solve the problem, as yet again, invoking them within a
> command-substitution will produce no information. The same problem would
> be true of using the other syntax you describe: I still have no
> available means to run the commands every time the prompt is issued,
> apart from within command substitution, which will kill the job-state
> info. Is there any way to get what I want executing in the "current" shell?
>
> Also, had you meant to post this reply to the list? It appears to have
> been sent to me only.
Yes, of course, I had meant to send it to the list. My mistake.
*sheepish grin*. So, you're right - the special variable $jobtexts
wouldn't match up in the subshell, but you could do something like
this:
$ function precmd {
export jt=""
for i in ${(kv)jobtexts}; jt="$jt:${i%% *}"
jt=${jt#:}
}
$ echo $jt
1:find:2:sleep
$ echo $(echo $jt)
1:find:2:sleep
And then you have a not-special, not-array version of jobtexts
exported into the environment of subshells that you can manipulate
however you want - and it even lets you remove the ugly dependence on
awk. ;-)
(precmd is a function that gets called every time the editor is about
to display a prompt, FYI).
Like I said, though - even though this should take no effort
whatsoever to do with zsh - no more than 5 lines or so - it would be
difficult to maintain compatibility with bash.
The best way I can think of to do what you want, off the top of my
head, is the following:
function precmd {
psvar[1]=""
# For each key and each value in jobtexts
for i in ${(kv)jobtexts}; do
# Come up with a separator between psvar[1] and this text
if [[ $sep == " " ]]; then
sep=":"
else
sep=" "
fi
# Then tack it on to the end of psvar[1] - Removing from
# the first space to the end of the element, if it has a space
psvar[1]="${psvar[1]}$sep${i%% *}"
done
# Remove leading space we accidentally inserted
psvar[1]=${psvar[1]# }
}
and
# Tell the prompt to reference psvar[1] (%?v == psvar[?])
PS1='micah(%1v)'
You don't even need to use prompt_subst.
Frankly, I'd just make your script check for ZSH right off the bat and
do it the simple way, leaving the complicated stuff for shells that
don't give you an elegant solution.
~Matt
next prev parent reply other threads:[~2007-03-08 21:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 19:27 Micah Cowan
[not found] ` <17393e3e0703081155o7a240628t49fae220ac9f49ae@mail.gmail.com>
[not found] ` <45F070A9.5060502@cowan.name>
2007-03-08 21:19 ` Matt Wozniski [this message]
2007-03-08 22:00 ` Micah Cowan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17393e3e0703081319r7a77aaf0w24f856abc5c7ea5c@mail.gmail.com \
--to=godlygeek@gmail.com \
--cc=zsh-users@sunsite.dk \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).