home dir executable (!/bin/sh, chmod+x) shell scripts won't run without "sh <script>"

[James Harrison]

On Mon, 2008-01-07 at 10:50 -0600, Erik Osterholm wrote:
> On Mon, Jan 07, 2008 at 09:13:39AM -0700, Steve Franks wrote:
> > > This is a sort of 'don't shoot yourself in the foot' design.  You
> > > cannot run a script or binary simply by name if you're cwd is the
> > > directory that contains that script or binary.  IIRC, you can't cd /
> > > usr/bin and run anything in /usr/bin without explicitly calling that
> > > file with the ./ telling the system THIS ONE.
> > 
> > Ah!  You'd think any one of the many tutorials I read would have
> > mentioned that little detail ;)
> > 
> > Thanks, all
> > Steve
> 
> You should search your tutorials for the PATH environment variable.
> 
> In an over-simplified nutshell, when you type a command in your shell,
> it checks a number of different locations for the place to find the
> command you're trying to execute.  Some of those locations are every
> directory specified in your PATH variable.  My PATH is:
> /bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin
> 
> This means that when I type 'ls', the shell looks for an executable
> named 'ls' in each of those directories (actually, it probably stops
> right after /bin/ls, since that's the correct one.)
> 

It stops at the first instance of an ls binary it finds. 

This is actually something that's really useful to know in all kinds of
circumstances. Your path is search from left to right, and it stops
searching at the first instance of the executable that it finds. This
has practical applications even when installing ports.

One example that comes to mind is the CUPS port. It installs its own
version of the lpr binary in /usr/local/bin. However, there's also an
instance of lpr, the BSD version, in /usr/bin. So how do you make sure
you're using the CUPS version of the binary?

The recommended way is a simple path edit, so that /usr/local/bin
appears before /usr/bin in the path. This way, your OS will use
the /usr/local/bin/lpr binary, leaving the system one untouched and, if
you ever want to revert to the system one you can simply switch the path
again. You can also accomplish a similar thing with symlinks, but this
is one useful idea for using the path.



> If the shell does not find a valid executable in the path, it will say
> that there is no such file or directory.  In this case, you would try
> specifying the full path by typing /bin/ls, or /home/user/scriptname.
> '.' and '..' have special meanings--current directory and
> next-directory-up, specifically--so if your current working directory
> is /home/user, typing ./scriptname will be largely equivalent to
> typing /home/user/scriptname.  ../scriptname would be largely
> equivalent to /home/scriptname.  This is why some people suggested
> trying ./scriptname in other e-mails in this thread.
> 
> The '.' notation for the current working directory enables you to add
> the current directory you happen to be in as part of your path (thus
> making it searched when executing a command), however this has serious
> security implciations, so if you think that it's something you really
> want to do, you'll have to find out from someone else how to do it.
> 
> erik
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"