I have a really odd bash error which I can't diagnose at all at the moment.
It refuses to run any script in the current directory when running as bash. If I run sh instead it works.
E.g. I have a script called 'build' in /home/chris/ikiwiki
Whether or not it has #!/bin/bash at the top of it then when I enter 'build' I get the error:-
bash: ./build: No such file or directory
However if I put #!/bin/sh at the top of the script (or if I run sh) then it runs without problems.
Ah, I have a clue, it seems as if bash doesn't want to run scripts which are in the current directory even though . is on my path. Is there some sort of clever security flag in bash that prevents this?
If a script is in (for example) /home/chris/bin (which is on my path) it runs OK with a #!/bin/bash at the top, however if the script is in the current directory I get the error even though . is on my path.
Wierd! Does anyone have any ideas what might be wrong? I'm sure it didn't used to be like this.
On Wed, Dec 20, 2006 at 11:37:08PM +0000, Wayne Stallwood wrote:
On Wed, 2006-12-20 at 22:59 +0000, cl@isbd.net wrote:
even though . is on my path.
oooh I used to punish people for doing that, normally by having a script called ls that relinked their home dir somewhere else :-)
It's a no, no for root of course but it's a big convenience for an ordinary user. Since I'm the only user (and I'm the admin) I don't feel too unsafe doing it.
On Thursday 21 December 2006 08:46, cl@isbd.net wrote:
On Wed, Dec 20, 2006 at 11:37:08PM +0000, Wayne Stallwood wrote:
On Wed, 2006-12-20 at 22:59 +0000, cl@isbd.net wrote:
even though . is on my path.
oooh I used to punish people for doing that, normally by having a script called ls that relinked their home dir somewhere else :-)
It's a no, no for root of course but it's a big convenience for an ordinary user. Since I'm the only user (and I'm the admin) I don't feel too unsafe doing it.
Interesting. For me, that would make no sense and would be a big inconvenience if it were assumed in my scripts(although it's not as if it's ever likely to be forced on me, heh). You know where you are with dotslash if you want it - quite literally of course.
I do keep a pathed-up-for-that-user folder in every home directory (/home/me/scripts or whatever), which is a fairly common take on the same sort of thing, I suppose. :-)
Ten.
On Thu, Dec 21, 2006 at 02:37:33PM +0000, Ten wrote:
On Thursday 21 December 2006 08:46, cl@isbd.net wrote:
On Wed, Dec 20, 2006 at 11:37:08PM +0000, Wayne Stallwood wrote:
On Wed, 2006-12-20 at 22:59 +0000, cl@isbd.net wrote:
even though . is on my path.
oooh I used to punish people for doing that, normally by having a script called ls that relinked their home dir somewhere else :-)
It's a no, no for root of course but it's a big convenience for an ordinary user. Since I'm the only user (and I'm the admin) I don't feel too unsafe doing it.
Interesting. For me, that would make no sense and would be a big inconvenience if it were assumed in my scripts(although it's not as if it's ever likely to be forced on me, heh). You know where you are with dotslash if you want it - quite literally of course.
The trouble is in this case that even if I enter:-
./build
I still get the error:-
/bin/bash: ./build: No such file or directory
even though there is a build in the current directory and it's executable by me. Not to mention that sh can run it fine.
I do keep a pathed-up-for-that-user folder in every home directory (/home/me/scripts or whatever), which is a fairly common take on the same sort of thing, I suppose. :-)
Ten.
cl@isbd.net wrote:
I still get the error:- /bin/bash: ./build: No such file or directory even though there is a build in the current directory and it's executable by me. Not to mention that sh can run it fine.
Is there a control character (often ^M) at the end of the first line? That's a pretty common cause of problems like the above - the system looks for a file called bash^M in /bin and it's not there...
Hope that helps,
On Fri, Dec 22, 2006 at 10:12:55AM +0000, MJ Ray wrote:
cl@isbd.net wrote:
I still get the error:- /bin/bash: ./build: No such file or directory even though there is a build in the current directory and it's executable by me. Not to mention that sh can run it fine.
Is there a control character (often ^M) at the end of the first line? That's a pretty common cause of problems like the above - the system looks for a file called bash^M in /bin and it's not there...
I found the problem at last. I have BASH_ENV set in my environment so that a .bashrc script is executed every time I run a non-interactive bash. Thus when I run ./build the ~/.bashrc gets run. The problem is that there's a "cd /home/chris" in the .bashrc file which of course breaks things completely - as I have just seen!
I either need to change things so that I don't use BASH_ENV to run the .bashrc (I need to run it for non-login shells but not for non-interactive shells) or I need to remove that offending cd.
On 22-Dec-06 cl@isbd.net wrote:
[...] I either need to change things so that I don't use BASH_ENV to run the .bashrc (I need to run it for non-login shells but not for non-interactive shells) or I need to remove that offending cd.
I think I'd remove that offending cd! Its presence embodies an assumption that every such script needs to be run in /home/chris, which as you've clearly demonstrated can be inappropriate.
However, that could involve you in some tedious (and error-prone) housekeeping.
If some (most?) of your scripts require a particular directory, then after removing cd /home/chris from the .bashrc you'd need to put it explicitly into every script which depends on it.
Cheers, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 22-Dec-06 Time: 11:17:38 ------------------------------ XFMail ------------------------------
On Fri, Dec 22, 2006 at 11:17:41AM -0000, Ted Harding wrote:
On 22-Dec-06 cl@isbd.net wrote:
[...] I either need to change things so that I don't use BASH_ENV to run the .bashrc (I need to run it for non-login shells but not for non-interactive shells) or I need to remove that offending cd.
I think I'd remove that offending cd! Its presence embodies an assumption that every such script needs to be run in /home/chris, which as you've clearly demonstrated can be inappropriate.
It's easy enough, all it needed was to remember where I had cd'ed from and then restore it. e.g.:-
olddir=`pwd` # do things that require a specific directory cd $olddir
-
cl＠isbd.net -
MJ Ray -
Ted.Harding＠nessie.mcc.ac.uk -
Ten -
Wayne Stallwood