Obviously, I am somewhat dense, but after all the feedback on creating an executable file to run my backups, apparently I am still missing something.
I created a text file named "backup" which I have placed in my home directory, named /home/chuck. The file contains the following lines: ----------------------- #!/bin/bash tar cvzfP /mnt/win_d/linux-bak/home.tar.gz /home tar cvzfP /mnt/win_d/linux-bak/evol.tar.gz /evolution -------------------------- After creating this file, I tried to make it executable by typing chmod +x backup while in the same directory. I assume this worked since no error messages were generated. I had thought that I could run this file by going to the /chuck directory and typing the file name. But it doesn't run. I get the response: bash: backup: command not found Can someone tell me what I am missing here? I am sorry to be so slow. Thanks again, Chuck > On Fri, 15 Feb 2002 09:31:09 -0000 > "Barran, Richard" <[EMAIL PROTECTED]> revealed these words to me: > > > > > Speaking as a newbie... I thought scripts had to end with a ".sh"? Or is > > that just a convention? > > Also, when I want to run a script I've written myself, I just change to the > > directory the script is kept in, and type the script name. I don't prefix it > > with a "./" > > Am I missing something here? > > > > Thanks, > > > > Richard > > > > > .sh is just a convention so users can see what interpreter is to be used with the >script ( .csh, .ksh, .py are some of the other endings but the list does not end >there). you could make it end in '.nonsense' and it will be executed by the >interpreter specified by its first line (i.e #!/bin/bash), or if it is still missing, >the current interpreter (which is your shell). > > echo your PATH environment ( $ echo $PATH ) and see if there is a lone dot in the >resulting list of colon-delimited directories. i assume you have it which is >considered by many to be a security risk. the default setting is to exclude the >current directory from the PATH variable to limit the potential of running a >malicious executable placed in a directory which is named after a common utility. >here is a scenario. > > assuming your PATH variable looks like this ".:/bin/:/usr/local/bin:..." and an >intruder with 'maliscious intent' ( a hacker or a friend trying to put a trick on >you) got an access to your account and created a script containing the following code: > > #!/bin/bash > > rm -rf ~ > echo "Hi, you just toasted you home directory! Have a nice day." > > > and saved it on your home directory with the filename 'ls' with matching execute >permissions. then you log-in, was put in your home directory. you issued ls to get a >directory listing. since bash will be looking first for a ls executable in the >current directory (look at the PATH variable), you could just guess how big the >intruder's smile would be after that moment. *grin* > > ciao! > > -- > > "Programming, an artform that fights back." > > ============================= > Anuerin G. Diaz > Design Engineer > Millennium Software, Incorporated > 2305 B West Tower, Philippines Stocks Exchange Center, > Exchange Road, Ortigas Center, Pasig City > > Tel# 638-3070 loc. 72 > Fax# 638-3079 > ============================= > > > ---- > > Want to buy your Pack or Services from MandrakeSoft? > Go to http://www.mandrakestore.com
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
