RE: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Franks Sent: 07 January 2008 15:53 I keep reading about making sh scripts executable with #!/bin/sh on the first line and chmod to executable. That works with all my system scripts (rc, etc.) or my system would be DOA, no doubt. When I do it in my home folder, however, running script gives command not found. I've only read about 5 sites telling you how to make shell scripts executable, they all say the same thing, and they all don't work. How did I get to be so special? [EMAIL PROTECTED] Steve, How are you running the commands? The problem is probably to do with your path. Your home directory isn't typically and shouldn't be in your PATH (try echo $PATH). You need to specify the full path to your scripts or place a ./ in front of the script name if in the same directory. e.g. ./myscript.sh or /home/username/myscript.sh - Barry ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
On Jan 7, 2008, at 9:52 AM, Steve Franks wrote: I keep reading about making sh scripts executable with #!/bin/sh on the first line and chmod to executable. That works with all my system scripts (rc, etc.) or my system would be DOA, no doubt. When I do it in my home folder, however, running script gives command not found. I've only read about 5 sites telling you how to make shell scripts executable, they all say the same thing, and they all don't work. How did I get to be so special? Steve Steve, 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. The reason for this is to prevent someone, a shady fellow, from putting a shell script in, say, a shared directory called ls, and making it executable, and have some similarly shady code such as: #!/bin/sh take_over_world(now); exit 0; Or something like that. ;) HTH - Eric F Crist Secure Computing Networks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
I keep reading about making sh scripts executable with #!/bin/sh on the first line and chmod to executable. That works with all my system scripts (rc, etc.) or my system would be DOA, no doubt. When I do it in my home folder, however, running script gives command not found. That typically indicates the path you've specified in the sh-bang does not exist. Another common problem there is if the shell script was written out in DOS format. If you're certain the first line looks proper, and that the path exists (/bin/sh most certainly should), try: perl -p -i -e 's/\r\n/\n/' foo.sh Then see if it works. scripts executable, they all say the same thing, and they all don't work. How did I get to be so special? It's possible the partition /home is mounted on is mounted with noexec, but in that case, I'd expect you'd get a permission denied message, rather than command not found. Josh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
How are you running the commands? The problem is probably to do with your path. Your home directory isn't typically and shouldn't be in your PATH (try echo $PATH). You need to specify the full path to your scripts or place a ./ in front of the script name if in the same directory. e.g. ./myscript.sh or /home/username/myscript.sh Ahh I misunderstood his email. Yes, most likely he is running it with foo.sh rather than ./foo.sh or /full/path/to/foo.sh Josh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
Hey Steve, Steve Franks wrote: Ah! You'd think any one of the many tutorials I read would have mentioned that little detail ;) Tutorials do have a tendency to look over important details. That's why I would always recommend a good book, something like UNIX Power Tools in your case, which, if not explains, then at least mentions most of the little things. JimBow ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
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.) 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
On Mon, Jan 07, 2008 at 10:50:47AM -0600, Erik Osterholm wrote: 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. OTOH, having ~/bin in the path has no security implications at all - assuming your scripts are OK, of course. -- Shenanigans! Shenanigans!Best of 3! -- Flash ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
On January 7, 2008 12:04:39 pm Mike Bristow wrote: On Mon, Jan 07, 2008 at 10:50:47AM -0600, Erik Osterholm wrote: 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. OTOH, having ~/bin in the path has no security implications at all - assuming your scripts are OK, of course. I don't see anything especially bad about putting . as the last item in the PATH on a personal desktop machine. It is convenient, IMHO worth the risk. If my desktop gets hacked, I have worse problems to worry about than this. -- Mike Jeays http://www.jeays.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
James Harrison writes: 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. There's another way, though one with implications - add: CUPS_OVERWRITE_BASE=yes to /etc/make.conf. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
In response to Mike Jeays [EMAIL PROTECTED]: On January 7, 2008 12:04:39 pm Mike Bristow wrote: On Mon, Jan 07, 2008 at 10:50:47AM -0600, Erik Osterholm wrote: 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. OTOH, having ~/bin in the path has no security implications at all - assuming your scripts are OK, of course. I don't see anything especially bad about putting . as the last item in the PATH on a personal desktop machine. It is convenient, IMHO worth the risk. If my desktop gets hacked, I have worse problems to worry about than this. Personally, I recommend creating a ~/bin directory and adding that to your search path. You're much less likely to accidentally download a trojan script into ~/bin than you are to ~, and it serves to keep your stuff more organized. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: home dir executable (!/bin/sh, chmod+x) shell scripts won't run without sh script
On Mon, Jan 07, 2008 at 01:21:46PM -0500, Robert Huff wrote: James Harrison writes: 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. There's another way, though one with implications - add: CUPS_OVERWRITE_BASE=yes to /etc/make.conf. Another alternative would be to remove the system binaries (and add NO_LPR= to /etc/make.conf to prevent its reinstallation during a build/installworld). Cheers. -- Jonathan Chen [EMAIL PROTECTED] --- I love deadlines. I like the whooshing sound they make as they fly by - Douglas Adams ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
