Problems with usage of «$(type -p "${TM_RUBY:-ruby}")» in commands

[Martin Kühl-3]

I recently ran into problems running scripts from TM and traced the cause to
having defined `ruby` as a shell function that launched `irb` when called
without arguments. The investigation showed a number of uses of the
code snippet `$(type -p "${TM_RUBY:-ruby}")`, particularly in the
following idiom:

    export TM_RUBY=$(type -p "${TM_RUBY:-ruby}")

I think this idiom is problematic for two reasons, both of which can be fixed:

1. The launch path of `ruby` can contain spaces which the above expression
   doesn’t mask, resulting in erroneous values in the variable but no visible
   errors. Simple demonstration:

    $ export VAR=foo bar # Note that the additional `bar` is just ignored
    $ echo $VAR
    foo

  This problem can be fixed by quoting the subshell expression, like this:

   export TM_RUBY="$(type -p "${TM_RUBY:-ruby}")"

  (Yes, the parser works well enough not to choke on that kind of nesting.)

2. The simple `type -p` command will print the launch path _only_ when its
   argument would in fact be invoked from that path as a command. What this
   means is that when one defines a shell function called `ruby` (like I had),
   `type -p ruby` will generate the empty string. Demo:

    $ type -p ruby
    /usr/bin/ruby
    $ function ruby () { :; }
    $ type -p ruby

   This problem can be worked around by using which(1) instead of `type -p` to
   find the launch path. In my experience, a lot of wide-spread shell
   configurations actually make `which` an alias, which is why I commonly
   advise people to explicitly call which(1) in scripts. This would look like:

    export TM_RUBY="$(command which "${TM_RUBY:-ruby}")"

   or:

    export TM_RUBY="$(/usr/bin/which "${TM_RUBY:-ruby}")"

I’m also not sure why the ruby launch path is used in the commands at all, but
if, as it seems, that’s the accepted way, I hope these fixes will be
considered.

Thanks,
Martin
_______________________________________________
textmate-dev mailing list
textmate-dev@...
http://lists.macromates.com/listinfo/textmate-dev

[Allan Odgaard-4]

On 13 Oct 2009, at 16:01, Martin Kühl wrote:

> I recently ran into problems running scripts from TM and traced the  
> cause to
> having defined `ruby` as a shell function that launched `irb` when  
> called
> without arguments. The investigation showed a number of uses of the
> code snippet `$(type -p "${TM_RUBY:-ruby}")`, particularly in the
> following idiom:
>
>    export TM_RUBY=$(type -p "${TM_RUBY:-ruby}")
>
> I think this idiom is problematic for two reasons, both of which can  
> be fixed:
>
> 1. The launch path of `ruby` can contain spaces which the above  
> expression
>   doesn’t mask [...]
>
> 2. [...] This problem can be worked around by using which(1) instead  
> of `type -p`

It’s ironic because the reason we have used ‘type -p’ over  
‘which’ is because ‘which’ had a bug related to PATH containing  
spaces. A space could easily appear in the PATH for TextMate commands  
since we add "$TM_SUPPORT/bin" which (for users with svn checkout)  
will expand to “…/Application Support/…”.

> I’m also not sure why the ruby launch path is used in the commands  
> at all

A few commands needed the fully resolved path because they would  
reference it later, but go through some hoops that wouldn’t ensure  
that the environment was preserved, e.g. HTML output →  
TextMate.system() from JavaScript (which now does have same  
environment as original command). So the TM command would ensure  
TM_RUBY was setup, and all JavaScript generated would expand TM_RUBY  
and insert the value of that or similar.

So basically both the resolving to full path and the use of ‘type -
p’ is for historic reasons (lack of quotes is just classic mistake).  
Presumably most of this can simply be removed. Also, lots of places  
where the idiom is used, it is simply copy/paste.

Adding to this, calling user’s shell startup files (so you get your  
ruby alias which is causing the clash) is another thing done for  
“historic reasons” (to ensure the user got same PATH in TextMate as  
his “LaTeX installer” (or similar) had setup for him in Terminal)  
— this is not done for commands with shebang, which we have mostly  
migrated to (sort of the transition to get away from this), so today  
this PATH inheritance convenience is not really the case anymore,  
which makes me think it is time to actually just drop sourcing user  
startup files.


_______________________________________________
textmate-dev mailing list
textmate-dev@...
http://lists.macromates.com/listinfo/textmate-dev