On Sun, Apr 28, 2013 at 01:29:28PM +, Thorsten Glaser wrote:
> Peter Hofmann dixit:
>
> >I believe you can work around all these issues by simply prefixing the
> >command piped to the shell with an "exec":
> >
> > dmenu_path | dmenu "$@" | sed 's/^/exec /' | ${SHELL:-"/bin/sh"} &
>
> Won'
Peter Hofmann dixit:
>I believe you can work around all these issues by simply prefixing the
>command piped to the shell with an "exec":
>
> dmenu_path | dmenu "$@" | sed 's/^/exec /' | ${SHELL:-"/bin/sh"} &
Won't necessarily work if the result is not a simple command, though…
FWIW:
tg@bl
Hi,
On Sat, Apr 27, 2013 at 10:15:12PM +0100, Ross Lagerwall wrote:
> If you type: a\ b "c d" e
> then it will try and execute the program "a b" and pass it two arguments,
> "c d" and "e".
that might work, but something like this won't:
xterm -hold -e bash -c 'echo "hello world"'
On Sat, Apr 27, 2013 at 09:41:22PM +, Thorsten Glaser wrote:
> Ross Lagerwall dixit:
>
> >+eval exec $(dmenu_path | dmenu "$@")
>
> You might need double-quotes around that (the eval argument).
> Best to check with something containing a tab, e.g.
> 「a\↹b "c↹d" e」 where ↹ is a tab. Sometimes
Ross Lagerwall dixit:
>+eval exec $(dmenu_path | dmenu "$@")
You might need double-quotes around that (the eval argument).
Best to check with something containing a tab, e.g.
「a\↹b "c↹d" e」 where ↹ is a tab. Sometimes spaces and
quotes are not enough to show the issues.
bye,
//mirabilos
--
“It
The previous logic leaves a shell running for the duration that the
launched application runs.
This changes it so that the only application that is left running is
the launched application.
---
OK, so here is another attempt. It should hopefully behave like the
current master branch (without the s
