Is there a reason applications run with $SHELL -i? about j4-dmenu-desktop HOT 12 CLOSED

-i is used so that the shell loads it's .rc files for custom aliases and
shell functions.

On 07/14/2014 11:30 AM, Patrice Peterson wrote:

See subject line. I'm using bash as my $SHELL, but I'm using fish for
interactive shells. Thus, running |"$SHELL -i -c "| drops me
into a fish shell without actually running the command.

When I drop the "-i" from the command invocation, things work fine. It
also seems to me that this is actually the "proper" way to run a
command, since the shell isn't supposed to be interactive.

This isn't meant to be inciteful or anything, I'm honestly just curious.
If this is intended behavior, I'll see if I can work around it myself.

—
Reply to this email directly or view it on GitHub
#26.

from j4-dmenu-desktop.

Would it be possible for j4-dmenu-desktop to always run /bin/sh instead of $SHELL ?

from j4-dmenu-desktop.

What would be the point of calling it via /bin/sh instead of just calling an application directly? You miss out on the ability to reference aliases in your shell, and you've just added an extra layer of indirection. Perhaps the ability to specify a shell other than default, or add support for fish would be a better alternative?

Although it works with fish for me:

fish -i -c '/bin/ls /'

apps bin boot ...

I'm using fish v2.1.1 if that helps. What version are you seeing that issue with runiq?

from j4-dmenu-desktop.

Would it be possible for j4-dmenu-desktop to always run /bin/sh instead of $SHELL ?

You can change $SHELL in the environment of j4-d-d

from j4-dmenu-desktop.

Calling the application directly is better, of course. I asked about /bin/sh because when I run j4-dmenu-desktop from the command line and launch for example dolphin, I saw this:

/usr/bin/zsh -i -c 'dolphin  -caption Dolphin '

I would expect:

dolphin  -caption Dolphin

or maybe:

/bin/sh -c 'dolphin  -caption Dolphin '

but I can see your point to have access to shell aliases or at least access to shell functions (no -i option required?).

Running on Arch: j4-dmenu-desktop 2.11-1 [installed].

from j4-dmenu-desktop.

-i reads in the config files to define the aliases; shell functions would still work without it however.

I don't use shell aliases in that manner myself, but I can see that some people might want to, and every shell i've ever seen supports -i/-c without issues. The only downside is an extra subshell being executed, but the overhead from that is pretty minimal.

from j4-dmenu-desktop.

Yes, but why is dolphin, in my example, not run directly from j4-dmenu-desktop?

from j4-dmenu-desktop.

Because it is easier to call "$SHELL -i -c '$command'" than it is to try and detect if it is an external app, or look up whether or not it is an alias, and then accomodate all the different shell's ways of defining aliases.

What issue is it causing by using the current method to call out to an external shell?

IMO enkore should be fine to close this bug since -i -c works perfectly fine with the latest fish shell, and he has also answered the why part already.

from j4-dmenu-desktop.

IMO enkore should be fine to close this bug since -i -c works perfectly fine with the latest fish shell, and he has also answered the why part already.

Dito

from j4-dmenu-desktop.

What issue is it causing by using the current method to call out to an external shell?

No real issue running an external shell and with the '-i' option, except that since aliases are for interactive use in the terminal, they may not be suitable for non-interactive use, such as launching them from j4-dmenu-desktop. Or does j4-dmenu-desktop launch a terminal if the command is an alias? (No). Only shell scripts and shell functions are suitable for both interactive and non-interactive use (i.e. suitable for launching from j4-dmenu-desktop). Note: a current workaround for ignoring the '-i' option (that is, removing the use of aliases, but also shell functions) is:

$ SHELL=/bin/sh j4-dmenu-desktop

(
In a new github issue? :
Maybe there should be an option to call "$command" directly. Isn't that how most desktop launchers operate? Maybe that option should be the default.
)

from j4-dmenu-desktop.

Maybe there should be an option to call "$command" directly. Isn't that how most desktop launchers operate? Maybe that option should be the default.

I would merge such a pull request, given it contains tests proving it is properly implemented.

No real issue running an external shell and with the '-i' option, except that since aliases are for interactive use in the terminal, they may not be suitable for non-interactive use

Not an issue. This is mainly a feature for people who want to run shell commands quickly without the need to see the result or open a shell window. This implies the people typing an alias into j4-d-d know what it does. Note that a desktop file usually specifies Exec with a full path, preventing any shell function or alias being executed as the result of selecting a desktop entry.

from j4-dmenu-desktop.

I agree, it's a nice extra feature, eventhough the user should really convert aliases to shell scripts if he wants to call them from any desktop launcher.

However, maybe the use of aliases should be an implicit (opt-in, non-default) option. Because how can you expect users to be aware that aliases (with possible side-effects) could be used?

This implies the people typing an alias into j4-d-d know what it does.

No. Aliases can have the same name as the command (stupid example: alias ls='ls --color'). As other desktop launchers don't use aliases, as far as I know, there is no reason for users to suspect that aliases could be used.

Note that a desktop file usually specifies Exec with a full path.

No. Most Exec commands don't include a full path:

$ grep -R "Exec=" /usr/share/applications/

That's another reason not to use aliases to launch programs (by default).

[Edit: corrected text formatting errors.]

from j4-dmenu-desktop.