Aliases and Run Command in Shell

[1.61803]

[alias] ⇥ Run Command in Shell

doesn't work in 1.0.0, all plugins updated.

Console logs

30.3.13 9:30:20.780 PM Quicksilver[43757]: Task failed.

Same thing with a command that I recently installed in /usr/local/bin/

sudo spoof-mac randomize en0

[Rob McBroom]

On Mar 30, 2013, at 4:51 PM, 1.61803 <iam...@gmail.com> wrote:

> [alias] ⇥ Run Command in Shell
>
> doesn't work in 1.0.0, all plugins updated.

What do you mean by alias? An alias defined in your shell, or a file alias that points to the command?

--
Rob McBroom
<http://www.skurfer.com/>

[1.61803]

On Monday, April 1, 2013 3:22:57 PM UTC+2, Rob McBroom wrote:

What do you mean by alias? An alias defined in your shell, or a file alias that points to the command?

Alias in shell profile. And non-default commands like brightness or spoof-mac.

[Rob McBroom]

On Apr 1, 2013, at 9:35 AM, "1.61803" <iam...@gmail.com> wrote:

> Alias in shell profile. And non-default commands like brightness or spoof-mac.

I haven’t looked, but I’m guessing the commands are run with the Bourne shell. That would explain both problems.

[1.61803]

On Monday, April 1, 2013 3:43:28 PM UTC+2, Rob McBroom wrote:

I haven’t looked, but I’m guessing the commands are run with the Bourne shell. That would explain both problems.

I'm missing something. Bash is my shell.

I'd expect aliases, non-default commands or whatever I write in the first panel for that matter to run in the default shell via that action as they usually directly do. 

[Rob McBroom]

On Apr 1, 2013, at 9:59 AM, "1.61803" <iam...@gmail.com> wrote:

> I'm missing something. Bash is my shell.

That’s the “Bourne Again” shell. The Bourne shell is `/bin/sh`.

[1.61803]

On Monday, April 1, 2013 4:01:24 PM UTC+2, Rob McBroom wrote:

That’s the “Bourne Again” shell. The Bourne shell is `/bin/sh`.

I know that, but would you elaborate your point?

The non-default commands I mentioned are btw compiled c and python.

[Rob McBroom]

On Apr 1, 2013, at 10:05 AM, "1.61803" <iam...@gmail.com> wrote:

> I know that, but would you elaborate your point?

Your aliases and non-default additions to the PATH environment variable are specific to your shell, bash. Other shells, like sh/tcsh/zsh, won’t pick up on these things. In Terminal, run `exec /bin/sh`.

Do any of those commands work there? Actually, they might. I seem to remember hearing long ago that `sh` was just `bash` on OS X. If that’s the case, there are some init files that are only read for an interactive login. Maybe your aliases and PATH need to be defined elsewhere to get picked up in all environments (and not just interactive Terminal sessions). See the man page for details.

[1.61803]

On Monday, April 1, 2013 4:20:54 PM UTC+2, Rob McBroom wrote:

In Terminal, run `exec /bin/sh`.
Do any of those commands work there?

Non-default commands run in sh, aliases don't.

Non-default commands won't run with Run Command in Shell.

 

I seem to remember hearing long ago that `sh` was just `bash` on OS X.

I remember at stackoverflow someone mentioned that in some systems sh is bash.

What does actually Run Command in Shell do? From what I mentioned above it's rather confusing.

Is it counterintuitive to think that whatever I write in the first panel be passed to the default shell?

[Jon Stovell]

In OS X, the sh executable is really bash, but bash run in a special mode by calling it as sh.

The reason none of your bash aliases work, 1.61803, is explained in this section from the bash man page:

       If  bash  is  invoked  with  the name sh, it tries to mimic the startup

       behavior of historical versions of sh as  closely  as  possible,  while

       conforming  to the POSIX standard as well.  When invoked as an interac-

       tive login shell, or a non-interactive shell with the  --login  option,

       it  first  attempts  to read and execute commands from /etc/profile and

       ~/.profile, in that order.  The  --noprofile  option  may  be  used  to

       inhibit  this  behavior.  When invoked as an interactive shell with the

       name sh, bash looks for the variable ENV, expands its value  if  it  is

       defined,  and uses the expanded value as the name of a file to read and

       execute.  Since a shell invoked as sh does not attempt to read and exe-

       cute  commands from any other startup files, the --rcfile option has no

       effect.  A non-interactive shell invoked with  the  name  sh  does  not

       attempt  to  read  any  other  startup files.  When invoked as sh, bash

       enters posix mode after the startup files are read.

In other words, Quicksilver is doing exactly what it is supposed to do by calling /bin/sh to run shell scripts, and /bin/sh is doing exactly what it is supposed to do when it ignores whatever you have in ~/.bash_profile, ~/.bash_login, and ~/.profile.

If you want the functions that you have put into your bash aliases to be available via Quicksilver, turn them into executable bash scripts and save them somewhere on your PATH (e.g. /usr/local/bin). Then you'll be able to call them no matter how you invoke a shell.

[Jon Stovell]

Actually, you'll need to put those bash scripts in /usr/bin or /usr/sbin. Turns out that /usr/local/bin isn't included in PATH variable for /bin/sh when it is called non-interactively.

[1.61803]

Thanks for the explanation, Jon.

This is what I found after some more testing.

echo $0 ⇥ Run Command in Shell returns /bin/sh

On Tuesday, April 2, 2013 5:12:10 AM UTC+2, Jon Stovell wrote:

In OS X, the sh executable is really bash, but bash run in a special mode by calling it as sh.

The reason none of your bash aliases work, 1.61803, is explained in this section from the bash man page:

       If  bash  is  invoked  with  the name sh, it tries to mimic the startup

       behavior of historical versions of sh as  closely  as  possible,  while

       conforming  to the POSIX standard as well.

This behaviour is not documented in the plugin.

Run Command in Shell is a misnomer. It could be Run Command in shell or Run Command in Shell(sh).

Nowadays this action could run in $SHELL or whatever executable path the user may input. @Rob, is it hardcoded?

And omt, non-default commands (except for one) run in sh but stderr is not handled by QS and logs _Quicksilver[43757]: Task failed._ Should I file a bug?

I'll keep testing and post results if I find something useful.

[Jon Stovell]

Well, it's not in the plugin's documentation because it isn't anything the plugin is doing or has any control over. That info comes from the bash man page, because that is how the shell behaves. Quicksilver is just being a good OS X citizen and following the rules for running non-interactive shells by using /bin/sh. For example, if you open an AppleScript and run do shell script "echo $0", you'll note that AppleScript also uses sh, and that if you try to use a bash alias in an AppleScript, that will fail, too.

Probably your best bet, 1.61803, is to follow the advice I gave another user here: https://github.com/quicksilver/Quicksilver/issues/1164

[1.61803]

On Tuesday, April 2, 2013 8:28:24 PM UTC+2, Jon Stovell wrote:

Quicksilver is just being a good OS X citizen and following the rules for running non-interactive shells by using /bin/sh.

I would make explicit this behaviour in the plugin's documentation. I thought QS was sending the command interactively in the background to $SHELL.

For example, if you open an AppleScript and run do shell script "echo $0", you'll note that AppleScript also uses sh, and that if you try to use a bash alias in an AppleScript, that will fail, too.

Not if you add -li options as below. Also, AppleScript logs the error — QS just logs 'Task failed'. Am I missing something?

 

Probably your best bet, 1.61803, is to follow the advice I gave another user here: https://github.com/quicksilver/Quicksilver/issues/1164

Thanks Jon for the script. I can use it with login and interactive options added to work properly.

using terms from application "Quıcĸsıɩⅴεʀ"

on process text theCommand

do shell script "/bin/bash -lic " & quoted form of theCommand

end process text

end using terms from

I know it's not the appropriate forum for this — but just in case anyone stumbles on something similar in QS, this is what I found/tried/done

- bash interactive

source /path/to/myAliasesFile in /private/etc/profile

- bash non-interactive (doesn't work)

export BASH_ENV=/path/to/myAliasesFile in /private/etc/private and shopt -s expand_aliases in myAliasesFile

- sh interactive

export ENV=/path/to/myAliasesFile in /private/etc/profile

- sh non-interactive

'A non-interactive shell invoked with the name sh does not attempt to read any other startup files.' bash man page > invocation

[Lucas Garron]

Would it be possible/reasonable to provide another action equivalent to "run this command the same way as if I'd typed it into Terminal using my default shell"? I know about the "right" behaviour, but sometimes I just want to be able to run a command (or create a trigger) without creating a bunch of wrappers to be able to use the commands I'm used to.

After some poking around on the internet, it seems the way to get a user's default shell is through DirectoryServices:

dscl . -read "/Users/$(whoami)" UserShell

»Lucas Garron

--
You received this message because you are subscribed to the Google Groups "Quicksilver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blacktree-quicks...@googlegroups.com.
To post to this group, send email to blacktree-...@googlegroups.com.
Visit this group at http://groups.google.com/group/blacktree-quicksilver?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[1.61803]

On Friday, April 5, 2013 7:04:38 AM UTC+2, lgarron wrote:

Would it be possible/reasonable to provide another action equivalent to "run this command the same way as if I'd typed it into Terminal using my default shell"?

Make the following change to the script from my previous post

do shell script "$SHELL -lic " & quoted form of theCommand

Check the man page for the details. Does it work for you?

[Lucas Garron]

Oh, interesting, $SHELL *does* work from the QS environment. But yes, that does work (does the -i matter?), and it does seem more robust than anything I've figured out.

»Lucas Garron

--

[1.61803]

On Friday, April 5, 2013 1:07:07 PM UTC+2, lgarron wrote:

Oh, interesting, $SHELL *does* work from the QS environment. But yes, that does work (does the -i matter?), and it does seem more robust than anything I've figured out.

$SHELL is an environment variable, passed along via AppleScript's do shell script

l is for login

i is for interactive

c is for command string

A new Terminal.app window gives a login and interactive type of shell interface.

This should achieve what you wanted — "run this command the same way as if I'd typed it into Terminal using my default shell".

Check bash man page for details, sections Options, Invocation and Shell Variables. It's right at your fingertips ;-)

[David Rees]

This follows from what was mentioned above, but as a tip, you can use do the middle line inside the AppleScript Editor to test your commands. And it will give you a much more useful error than QS does. For example, if you want to test how things will run inside sh:

do shell script "your command here" 

d