On Mon, Dec 02, 2019 at 08:51:27AM -0500, Greg Wooledge wrote:
> On Sun, Dec 01, 2019 at 03:20:54PM +0000, George R Goffe via Bug reports for
> the GNU Bourne Again SHell wrote:
> > mkdir ()
> > {
> > dirs="$@";
> > for dir in $dirs;
> > do
> > /bin/mkdir -p "$dir";
> > done
> > }
>
> This function is severely flawed. I believe this is what you wanted:
>
> mkdir() {
> command mkdir -p "$@"
> }
The original function, with a loop, may have been written to avoid
an error on getting a too long list of arguments. The loop can be
re-introduced in Greg's code like this:
mkdir_p () {
local dirpath
for dirpath do
command mkdir -p "$dirpath" || return
done
}
This would additionally stop as soon as there was an issue with creating
any of the directories (for example, due to permissions) and return the
exit status of the failing "mkdir -p".
mkdir_p () {
local dirpath err
err=0
for dirpath do
command mkdir -p "$dirpath" || err=$?
done
return "$err"
}
This would not stop at the first error, but would return the the most
recently failing mkdir's exit status to the caller if it failed to
create one or more of the directories.
I believe both alternatives are allowed in the mkdir POSIX description.
Regards,
Kusalananda
>
> Your function smashes an array into a string (using first-char-of-IFS
> as a delimiter), then breaks up that string using IFS, which may or
> may not reproduce the original array. There's no reason for that
> double conversion at all. On top of that, your function messes with
> two variables that aren't local to it.
>
> Either of those flaws could conceivably break a script that uses this
> function unexpectedly.
>
> Another way your function could break a script is if the script is
> *counting* on mkdir to perform the atomic make-or-fail-trying
> operation (no -p option), for example when trying to create a directory
> as a form of mutual exclusion locking. Adding -p breaks that usage
> of mkdir. Granted, I find it unlikely that a "make install" operation
> would be using mkdir in that highly specific way. But just in general,
> altering the basic operations of the core shell utilities is unwise.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
