Problem with PATH

Shell Programming and Scripting
1

Recently I lost a number of changes I made to a program when the SCO Unix system went down. The system "mail" suggested a "vi -r" option that took me back several days. To prevent this in the future, I am trying to create my own vi command:

if [ $# -eq 1 ]
  then
  cp -p $1 $1.bak
fi
/usr/bin/vi $*
if [ $# -eq 1 ]
  then
  rm $1.bak
fi

I put this in my home directory where my PATH in ".profile" is

PATH=.:/usr/shells:/bin:/etc:/usr/bin:/tcb/bin:/u/wbport

When looking at my home directory from another login, I don't see the .bak file. What am I missing?

------ Post updated at 03:50 PM ------

I could use it after logging off and then back on. If this looks like it would be useful, change the first if to

if [ $# -eq 1 -a -s $1 ]

If the file doesn't exist yet, there is nothing to back up.

The last if statement should be the same as the first one or just check for the presence of $1.bak .

2

I'm not sure what you think a PATH variable does. If a file has execute permissions (meaning you can run it by just typing the correct name of the file) then it can be run by typing the whole filename from anywhere

# example:
/path/to/shell.sh parameter1

This is awkward if you have your current directory somewhere else. So. PATH allows you to put directories into the variable. Then when you type the name no matter where your current directory is set, the PATH looks up the file, then lets you run it.

Example after adding the directory where shell.sh lives to PATH:

shell.sh parameter1

Not delete it
Not write to it.
Just execute it.

The which command helps you figure out what file you will execute before you try to run it. Why? Well, in the example: shell.sh could be in several places. So if you type shell.sh you could be running another script by accident. PATH can be a cause of this.

export PATH=".:${PATH}"

makes the current directory part of the PATH. Dangerous.

Example: I use t.shl as a throwaway temporary filename. So it could be in any of the my own directories.

which t.shl

tells me which one will run when I type the command.

3

which is from the csh.
The standard shell has type .
The ksh in SysV introduced whence .

I think the wrapper should cover all arguments

for f
do
  [ -s "$f" ] && cp "$f" "$f.bak" && echo "created $f.bak"
done
/usr/bin/vi "$@"
for f
do
  [ -f "$f.bak" ] && rm "$f.bak" && echo "removed $f.bak"
done

Unlike $* the "$@" can handle arguments with spaces. Some early shells have a bug, AFAIR the work-around was "${1+$@}"

vi "file name with spaces"

Last but not least, I think the best backup is built into vi and vi -r is a good recovery.

1 Like
4

You can make function to your .profile to overwrite external or builtin command, no need to setup PATH and create scriptfile.

Insert into .profile:

vi()
{
  for f in $@
  do
     [ -s "$f" ] && cp -f "$f" "$f.bak" && echo "created $f.bak"
  done

  /usr/bin/vi $@

  for f  in $@
  do
    [ -f "$f.bak" ] && rm "$f.bak" && echo "removed $f.bak"
  done
}
5

$@ muist be in quotes. Unquoted it will expand like $*

$ cat demo
echo '$@ - word splitting takes place'
for f in $@
do
  echo "$f"
done
echo '"$@" - quotes prevent word splitting; $@ (and [@] in arrays in later shells) split into arguments (elements) nevertheless'
for f in "$@"
do
  echo "$f"
done
$ /bin/sh demo "" 1 2 "3 4"
$@ - word splitting takes place
1
2
3
4
"$@" - quotes prevent word splitting; $@ (and [@] in arrays in later shells split into arguments (elements) nevertheless

1
2
3 4

As a last exercise try

/bin/sh demo "*"

You see that unquoted the shell does a glob-expansion against the current directory. (That you can prevent with set -f )

6

Right now my script look like:

if [ $# -eq 1 -a -s $1 ]
  then
  cp -p $1 $1.bak
echo "While using vi, $1.bak has been created."
sleep 1
fi
/usr/bin/vi $*
if [ -f $1.bak ]
  then
  rm $1.bak
fi

I realize vi can edit a number of files, start at a specific position, or after a search, but we seldom use any extra bells or whistles. Near the end of a Y2K conversion script, a vi searched for "-YEAR" in the command line, but that was 19 years ago.

Thanks for looking at it, I might revisit this thread and check for new ideas in the near future.