cd /root
for project in $(ls go-cicd);
I think a better expression would be: for project in ./*
do [ -d "$project" ] || continue
... cd /root
for project in $(ls go-cicd);
I think a better expression would be: for project in ./*
do [ -d "$project" ] || continue
...- Everything here is done as root. For the day that you want to build with lesser privilege, do this:
BLDUSER=~root
- That will be difficult for you, because you are moving the projects to /usr/local/bin; for the day that you stop running as root, make a subdirectory "/usr/local/bin/$BLDUSER" (owned by the namesake account) and move the projects there instead.- Very minor nitpick, use <<- and prefix tabs on the here document to make it slightly easier to read.
- Slight improvement, so this can print more than one argument:
println() { y=
for x
do printf %s%s "$y" "$x"
y=' '
done >> /root/gocicd.log
echo >> /root/gocicd.log # for the newline
}Given the situation and the project names, I wouldn't expect the use of `ls` described in TFA to ever be a problem, but doing it with a simple glob would still be nicer and is a good habit to get into overall since then you don't have to ask yourself "is this use of ls going to be safe?"
- Running ls forks an unnecessary process.
- The ls may be aliased with "-F" (or -p) which will corrupt the filenames.
- Environment variables may otherwise (unexpectedly) manipulate ls behavior.
- Files with spaces will not be evaluated correctly.
- Hostile files can be placed that mimic command line arguments.
The shell should evaluate filenames itself; it is very capable of doing so.
POSIX ls: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l...