Fixes #259 do not hardwire path of bash #260

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants

ruurd commented Oct 12, 2012

Fixes #259 do not hardwire path of bash.

I sort of assume that whenever is specific for cron and therefore it isn't necessary to accomodate for Windows users is that correct?

R

Owner

javan commented Oct 17, 2012

How about simply running which bash?

ruurd commented Oct 17, 2012

That implies executing a shell, executing which and then iterating over the path untill bash is found... instead of just iterating over the path until you find bash :-) And while on the subject of bash, why not just use sh instead?

Owner

javan commented Oct 17, 2012

which does the job of searching your path for you. Why reinvent that?

The which utility takes a list of command names and searches the path for
each executable file that would be run had these commands actually been
invoked.

ruurd commented Oct 17, 2012

it is not a question of reinventing the wheel it is a question of what is the most lightweight solution. Process creation (twice for each call) isn't exactly cheap under Linux. I /did/ consider using which but searched for this solution as an alternative specifically to circumvent process creation.

ruurd commented Oct 20, 2012

well either you can use this or use which but as long as the hardwire isn't solved there is a problem with FreeBSD which I happen to use... Yet another reason for me to provide this.

ruurd commented Nov 9, 2012

Another good reason to not use a subshell to run which to find out the path: you don't need to interpret the text result of which to determine if the result you have is valid.

ruurd commented Nov 9, 2012

And yes you really would help FreeBSD peeps if you merge this.

kronn commented Jan 1, 2013

how about simply specifying /usr/bin/env bash as shell? Would that work? Or is that one level too much?

alternatetly, I would prefer to have a configuration for the shell-path, defaulting to the current value. This way, the schedule.rb is more explicit and IMHO clearer.

ruurd commented Jan 2, 2013

A configuration entry for the shell is not what you really want - especially if you take into account that the path to the shell can be different on development and/or testing and/or production hosts and you really don't want that if you are going to specify that path in schedule.rb.

The env route could be a good solution but is env a utility that exists on all platforms and is always installed? Might be the case and I would prefer that to setting the path to the shell in schedule.rb

kronn commented Jan 3, 2013

On Ubuntu, env is in coreutils. On BSD, I expect it to be in the base system. I learned this pattern from NetBSD and always thought of it as the most portable method.

@javan javan closed this May 19, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment