UNIX creating a function that imitates the rm error conditions? - bash

I am stuck on this part of my project. How would I create a function to where if I put "sh remove filename" in the command line, it would act the same as "rm filename" and tests its error conditions and display the same error messages as the rm command? This is what I have so far but I don't think its right:

You've probably misunderstood the question which is summarized in :
if I put "sh remove filename" in the command line, it would act the
same as "rm filename"
Create a script named remove with the following content
# No shebang
# You need to check if a parameter is passed, omitting that for brevity
rm "$#" # Double quoting is crucial
Save it and run it as
sh remove "filename"
# Here sh which is probably a link to bash will interpret the contents in remove

Related

How to execute a test as part of bash string as executable command?

If I have a "file" that includes...
rm -rf /etc/motd
if [ -f /etc/motd]; then rm -rf /etc/motd; fi
And I try to do...
while read -r line
do
command ${line}
#$(${line})
#eval ${line}
done< "file"
The 1st line runs of course. But the 2nd command fails with if : command not found. Which I understand the error because not an explicit command. So the question is how to execute a test as part of a string as bash script logic? I tried eval, and $(), i.e. subshells, but still errors out? Tripping over the 'if' test. I need a conditional test before the command/script code is executed in a one-liner. There has to be a way to do this, right?
If your intention is to load and execute "file" from another script just do
source "file"
no need to loop over the lines.

command substitution not working in alias?

I wanted to make an alias for launching a vim session with all the c/header/makefiles, etc loaded into the buffer.
shopt -s extglob
alias vimc="files=$(ls -A *.?(c|h|mk|[1-9]) .gitconfig [mM]akefile 2>/dev/null); [[ -z $files ]] || vim $files"
When I run the command enclosed within the quotations from the shell, it works but when run as the alias itself, it does not. Running vimc, causes vim to launch only in the first matched file(which happens to be the Makefile) and the other files(names) are executed as commands for some reason(of course unsuccessfully). I tried fiddling around and it seems that the command substitution introduces the problem. Because running only the ls produces expected output.
I cannot use xargs with vim because it breaks the terminal display.
Can anyone explain what might be causing this ?
Here is some output:
$ ls
Makefile readme main.1 main.c header.h config.mk
$ vimc
main.1: command not found
main.c: command not found
.gitignore: command not found
header.h: command not found
config.mk: command not found
On an related note, would it be possible to do what I intend to do above in a "single line", i.e without storing it into a variable files and checking to see if it is empty, using only the output stream from ls?

set -x and wildcard expansion

In shell scripts, our corporate coding standard requires using...
set -x
command
set +x
...for logging, rather than...
echo "doing command"
command
However, when a wildcard is part of the command, this can produce very verbose output.
For example...
for i in {1..10}; do touch $i.foo; done; # create 10 foo files
set -x # log command execution (stdout to be redirected to log file)
rm *.foo # delete foo files
set +x # end logging
...produces the output...
rm 10.foo 1.foo 2.foo 3.foo 4.foo 5.foo 6.foo 7.foo 8.foo 9.foo
Okay for 10 files, but not so great for 10,000.
The desired output is...
rm *.foo
My first thought was to put *.foo in quotes...
rm "*.foo"
However, that gives the error...
rm: cannot remove ‘*.foo’: No such file or directory
Is there a way, using set -x, to echo the command without expanding the wildcard?
For many cases, where simple '-x' or '-v' do not work (as per comments above), and staying within your coding standard (no separate echo), consider:
VAR=/tmp/123
$SHELL -cv "ls $VAR/*"
which will execute the command, but will log the command WITH variable substitution, command substitution, but WITHOUT wild-card substitution.

csh doesn't recognize command with command line options beginning with --

I have an rsync command in my csh script like this:
#! /bin/csh -f
set source_dir = "blahDir/blahBlahDir"
set dest_dir = "foo/anotherFoo"
rsync -av --exclude=*.csv ${source_dir} ${dest_dir}
When I run this I get the following error:
rsync: No match.
If I remove the --exclude option it works. I wrote the equivalent script in bash and that works as expected
#/bin/bash -f
source_dir="blahDir/blahBlahDir"
dest_dir="foo/anotherFoo"
rsync -av --exclude=*.csv ${source_dir} ${dest_dir}
The problem is that this has to be done in csh only. Any ideas on how I can get his to work?
It's because csh is trying to expand --exclude=*.csv into a filename, and complaining because it cannot find a file matching that pattern.
You can get around this by enclosing the option in quotes:
rsynv -rv '--exclude=*.csv' ...
or escaping the asterisk:
rsynv -rv --exclude=\*.csv ...
This is a consequence of the way csh and bash differ in their default treatment of arguments with wildcards that don't match a file. csh will complain while bash will simply leave it alone.
You may think bash has chosen the better way but that's not necessarily so, as shown in the following transcript where you have a file matching the argument:
pax> touch -- '--file=xyzzy.csv' ; ls -- *.csv
--file=xyzzy.csv
pax> echo --file=*.csv
--file=xyzzy.csv
You can see there that the bash shell expands the argument rather than giving it to the program as is. Both sides have their pros and cons.

path of running bash script found when re-runs as sudo

The following code checks if you have root authority, then runs the script again with it :
CMDLN_ARGS="$#" # Command line arguments for this script (if any)
export CMDLN_ARGS
func_check_for_sudo() {
if [ ! $( id -u ) -eq 0 ]; then
echo "You may be asked for your login password for [`whoami`]." ;sleep 1
LAUNCH="`dirname \"${0}\"`"
exec sudo -S su -c ${LAUNCH}/$(basename ${0}) ${CMDLN_ARGS}
exit ${?}
fi
}
Where things are going wrong is when I place this script in a "$HOME/bin" folder or something so I can just launch it without the path. It gives me the error "No such file or directory". I need the script to get that information and correctly pass it to exec.
My question is this: how do I get the /path/to/script_name from within a script correctly when it is called without the path? To recap, I'm calling MY_SCRIPT insead /path/to/MY_SCRIPT which breaks my script because it has to check for root authority and run again if you don't have it.
Basically the line of code in question is this where ${0} is the script name (with path if you called it with one):
exec sudo -S su -c ${0} ${CMDLN_ARGS}
There are a couple of problems here:
Finding the path to the script. There are a couple of easy ways to do this: use "$BASH_SOURCE" instead of $0; or simply take advantage of the fact that (at least by default), sudo preserves $PATH, so sudo "$0" ... will resolve the script fine.
The second is that the script doesn't preserve its arguments properly. Spaces within arguments will be mistaken for breaks between arguments, and wildcards will be erroneously expanded. This is because CMDLN_ARGS="$#" mushes all the arguments together separated by spaces, and then ${CMDLN_ARGS} re-splits on spaces (maybe not the same way) and also expands wildcards.
Here's my take at correcting the problems. Note that putting the handler in a function just adds a layer of unnecessary complication, so I just put it inline. I also used sudo's -p option to clean up the prompting slightly.
if [ $( id -u ) -ne 0 ]; then
exec sudo -p "Login password for %p: " "$0" "$#"
exit $?
fi

Resources