I'm writing some small bash scripts for copiyng certain files/directories in GNU/Linux and Solaris. Everything is OK in Linux, but cp command hasn't the same options in Linux and Solaris.
Copy command is something like this:
cp -ruv $source $dest
Unfortunately I don't know how to achieve copy verbose and copy update in Solaris. Any idea?
Thanks
Unfortunately, cp under Solaris doesn't have that option. man solaris should reveal that.
Are you comfortable making your script depend on rsync?
Or, if possible, you can install the coreutils package and use GNU's cp.
I ran into a similar issue myself and found that gcp takes care of it too. I've made installing coreutils part of my standard system setup.
I run these on a new Solaris install:
pkgadd -d http://get.opencsw.org/now
pkgutil -U
pkgutil -i -y coreutils
pkgutil -a vim
pkgutil -i -y vim
pkgutil -i -y findutils
Remember to add the path - and the documentation path - to your profile, and possibly to the system profile at /etc/profile:
# Set the program path
PATH=$PATH:/usr/sfw/bin:/usr/sfw/sbin:/usr/openwin/bin:/opt/csw/bin:/usr/ccs/bin:/usr/local/bin:/usr/local
export PATH
# Set the documentation path
MANPATH="$MANPATH:/usr/share/man:/opt/sfw/man:/opt/csw/man"
export MANPATH
It sounds like you might be new to Solaris - as I am relatively new. I also do these, which shouldn't affect anything.
I set VIM as the default editor instead of VI - it's compatible, but has more features, including ANSI color, and some terminal emulators will pass your mouse clicks and scrolling through for even more flexibility:
# Set the default editor
EDITOR=vim
export EDITOR
Then if you are still using the default prompt that doesn't say anything, you might want to add some information - this version requires a Bash shell:
# Set the command prompt, which includes the username, host name, and the current path.
PS1='\u#\h:\w>'
export PS1
To recreate verbose mode, you can tee the output to the controlling terminal (/dev/tty) while the stdoout output of tee itself is passed to cp via xargs.
find /some/source/directory -type f | \
tee /dev/tty | xargs -I {} cp {} /copy/to/this-directory/
Replace the find with whatever you like, so long as it passes the paths to the files to be copied through the pipe to tee.
Tested on a standard Solaris 10 system without extra GNU utils.
Related
I install files using standard POSIX utilities cp, install, sed, sh.
It is possible to fix any permission with chmod / chown / chgrp but it is dangerous to temporarily expose sensitive data and fix it later.
"Standard" way to deal with the problem is to use install -m MODE -u USER -g GRP.
What if I need to process file with a "dumb" utility (like grep / sed / awk / sh )? How can I prevent data leak from such tools? By using umask 777?
I consider following dangerous:
base64 -d secret.txt >/etc/app.key
sed -e '/^#.*/d' </etc/default/app.cfg >/etc/app.cfg
because file content might be accessible to other users if umask is too open. Also I have to "fix" user/group after redirections...
PS Seems install is not in POSIX... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html
Also GNU install doesn't read from pipe, so following trick is impossible:
sed ... < $SRC | install -m MODE -u USER -g GRP - $DEST
Some shell allow process substitution (<(cmd) syntax) or one might create named pipe as workaround...
After reading POSIX I see that there is no guaranty for mkdir, cp and other tools to respect umask. Actually umask is a process property and is handled by kernel/syscals.
I'd better use non-standard GNU install with -m MODE (-u, -g).
For dumb tools GNU Bash with process substitution would be handy:
install -m 0700 <(sed ... $SRC) $DST
But I'm not sure of FIFO permissions...
Here is the part of the makefile that is giving me issues:
-#mv -f -t ./ $(LIBPATH)/userfiles/*
When I run the makefile on Ubuntu it works fine however when running on my Mac I get the following error:
mv: illegal option -- t usage: mv [-f | -i | -n] [-v] source target
mv [-f | -i | -n] [-v] source ... directory
The -t flag is not defined in the man pages of my mac so I'm wondering how I can get around this.
Just put the destination at the end like how mv is normally used:
-#mv -f $(LIBPATH)/userfiles/* .
You are allowed to have multiple sources (such as the expanded wildcard here). The last argument is the destination. The -t flag is just a way to change this ordering if you have to for some reason, and (as you discovered) it is not always available.
Install coreutils by typing the following command in the terminal:
brew install coreutils
Commands also provided by macOS and the commands dir, dircolors, vdir have been installed with the prefix "g".
If you need to use these commands with their normal names, you can add a "gnubin" directory to your PATH with:
PATH="$(brew --prefix)/opt/coreutils/libexec/gnubin:$PATH"
Reference:
coreutils - Homebrew Formulae
This question is similar to this one: https://serverfault.com/questions/342697/prevent-sudo-apt-get-etc-from-swallowing-pasted-input-to-stdin but the answer is not satisfying (appending && to each line of bash script is not elegant) and does not explain why some users can paste/execute multiple subsequent apt-get install -y commands and others can't because stdout is swollen by the next command.
I have a script my_script.sh:
sudo apt-get install -y graphicsmagick
sudo apt-get install -y libgraphicsmagick++1-dev
...
It can have only two lines or more of sudo apt-get install stuff. The libraries (graphicsmagick, etc.) doesn't matter, it can be any library.
When I copy this script and paste it's contents to bash or just execute it like this:
cat my_script.sh | sudo -i bash
then for some reason only the first line (graphicsmagick) gets executed and the rest is just printed to the console. It happens only with sudo apt-get install -y, other scripts, which doesn't contain this command behave normally.
If I change bash to sh (which is dash) I get expected behaviour:
cat my_script.sh | sudo -i sh
Can you explain why this happens?
When answering, can you please avoid this questions/comments:
Why are you doing it this way?
Piping to your bash is not safe
Some other aspects are not safe or hackish
I just want to know why bash doesn't work as I would expect and sh does.
PS. I'm using Ubuntu 14.04, sh is dash as you can see here:
vagrant#vagrant-ubuntu-trusty-64:/tmp$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Feb 19 2014 /bin/sh -> dash
Bash and dash simply behave different when using -i flag.
Bash always goes to interactive mode even when stdin is not a terminal.
Dash on the other hand will not go into interactive mode, even with -i flag.
Probably need the -s option
If the -s option is present, or if no arguments remain after option
processing, then commands are read from the standard input. This option allows
the positional parameters to be set when invoking an interactive shell.
Bash man page
curl -s http://foo.com/bar.sh | sudo -i bash -s
Example
On Linux, I have a --parents option available for the cp command so I can do
cp --parents test/withintest/go.rb test2
http://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html
On Mac, I do not have this option available. Is there a way to do this on Mac? Why is this option not available?
PS. The purpose of --parents is the following:
‘--parents’ Form the name of each destination file by appending to the
target directory a slash and the specified name of the source file.
The last argument given to cp must be the name of an existing
directory.
For example, the command:
cp --parents a/b/c existing_dir
copies the file a/b/c to existing_dir/a/b/c, creating any missing intermediate directories.
This bothered me quite a lot as well.
A workaround for this could be to use rsync.
rsync -R test/withintest/go.rb test2
has the same effect as cp --parents and OS X comes standard with rsync.
You can use the ditto command on Mac OS X:
The basic form
ditto <src-path> <dst-path>
does what you want. There's a lot more options too - check out the man page.
You can install the GNU version of cp using MacPorts.
After MacPorts is installed you can install the coreutils packages:
sudo port install coreutils
Then you will be able to use the GNU version cp and other core utilitites (ls, date, cat, etc.) by prefixing the command with a g:
gcp --parents test/withintest/go.rb test2
If you want these GNU versions to be used by default you can add the GNU bin update your path. Add the following to your ~/.bash_profile:
export PATH="/opt/local/libexec/gnubin:$PATH"
The Homebrew way:
Install coreutils
brew install coreutils
Use the GNU g- prefixed command
gcp --parents test/withintest/go.rb test2
I used rsync and what I did was:
rsync -R dir/**/file.json destination
Try
mkdir -p `dirname "$file_path"` && cp "$old_dir/$file_path" "$file_path"
This first creates the directory with all itermediates in the relative file path. Then it copies the file to the newly created directory.
I would not replace mac cp with GNU cp. I would also not used ditto because it is not cross-platform. Instead use cross-platform tools, such as rsync:
rsync <srcDir/srcFile> <dst>
Result: dst/srcDir/srcFile
The GNU/Linux version of cp has a nice --update flag:
-u, --update
copy only when the SOURCE file is newer than the destination file or when the destination file is missing
The Mac OS X version of cp lacks this flag.
What is the best way to get the behavior of cp --update by using built-in system command line programs? I want to avoid installing any extra tools (including the GNU version of cp).
rsync has an -u/--update option that works just like GNU cp:
$ rsync -u src dest
Also look at rsync's other options, which are probably what you actually want:
-l, --links copy symlinks as symlinks
-H, --hard-links preserve hard links
-p, --perms preserve permissions
--executability preserve executability
-o, --owner preserve owner (super-user only)
-g, --group preserve group
--devices preserve device files (super-user only)
--specials preserve special files
-D same as --devices --specials
-t, --times preserve times
-a, --archive
This is equivalent to -rlptgoD. It is a quick way of saying you want recursion
and want to preserve almost everything (with -H being a notable omission). The
only exception to the above equivalence is when --files-from is specified, in which
case -r is not implied.
Note that -a does not preserve hardlinks, because finding multiply-linked files is
expensive. You must separately specify -H.