UNIX for Dummies Questions & Answers

Hello Experts

let say we got a line a file named

Code:

/user/Oracle/my_catalog/default/root/webcat+backup+testing+07192011.atr

now i have to create a directory with name

Code:

webcat backup testing 07192011

by removing + and removing .atr at the given path...can it be possible

Please let me know your advice.

Thanks in advance

Code:

mkdir "$(echo "/user/Oracle/my_catalog/default/root/webcat+backup+testing+07192011.atr" |\
 awk -F\| '{gsub(/(+)/," ",$NF);gsub(/\.atr$/,""); print}')"

Code:

file_path=" /user/Oracle/my_catalog/default/root/webcat+backup+testing+07192011.atr"
dir_name=`echo $file_path | awk -F"[.+]" '{print $NF-1}`
mkdir $dir_name

In order to prevent the spaces in the new directory being seen as token separators when making the directory you'll have to either quote the new directory name or escape the spaces.
eg:

Code:

file="/user/Oracle/my_catalog/default/root/webcat+backup+testing+07192011.atr"
# escaping
basename $file|cut -d\. -f1|sed ' s/\([a-z0-9]\+\)+\+/\1\\ /g'
#quoting
echo \"$(basename $file|cut -d\. -f1|sed ' s/\([a-z0-9]\+\)+\+/\1 /g')\"

Though spaces in file paths is a shooting offence @ this site

A minor nit: It doesn't hurt anything, but the -d option-argument in cut does not need to be backslash-quoted. The dot is not a shell metacharacter.

A major nit: Your echo suggestion will not protect anything. Since the double quotes are escaped, the results of the command substitution will undergo field splitting. You're just getting lucky because the sample data never yields more than one consecutive space character and that just happens to be what echo uses to delimit its arguments in its output. If the filename contained consecutive + characters, the field splitting would effectively squeeze the resulting consecutive spaces into one.

If your intention with that suggestion is to output a quoted string with the correct number of spaces, then you need to use a set of unescaped quotes outside the backslash-escaped quotes. This additional set of quotes is needed for another reason as well: the shell performs pathname expansion (file globbing) after command substitution and field splitting. Should the filename contain filename pattern metacharacters (*, ?, [...]), and should that pattern match something, the result would be something unintended. A long shot, perhaps, but still, a window for error.

A less error-prone approach would be to simply stuff the command substitution's output into a variable (variable assignment does not undergo field splitting nor filename expansion).

Your sed invocation is needlessly complex. You could just use tr + ' ' or sed 'y/+/ /' to do that job.

To further simplify, basename and cut could be eliminated as well, with their functionality folded into a single sed:

Code:

dir=$(echo "$file" | sed 's/.*\///; s/\.atr$//; y/+/ /')
mkdir "$dir"

If posix-compliancy/portability is not a necessity, and if a modern shell is available, then the most efficient solution would be to leverage that shell's built-in features. The following should work with contemporary korn and bash shells (and perhaps others):

Code:

dir=${file##*/}       # delete directories (i.e. basename)
dir=${dir%.*}         # delete file extension
dir=${dir//+/ }       # replace all pluses with spaces
mkdir "$dir"

With regard to shooting someone over spaces in filenames, I reserve my bullets for tabs and newlines in filenames. Since UNIX and its userland is built around the text format which uses \t as the field/column delimiter and \n as the record/line delimiter, any file naming convention which uses them is truly and profoundly braindamaged. Such filenames make it impossible to use the plethora of text-oriented utilities to process filenames/pathnames. Spaces? Not so much. In my opinion, they're no big deal.

Regards,
Alister

---------- Post updated at 11:07 AM ---------- Previous update was at 10:57 AM ----------

Hmmm. I probably should have taken a closer look at the sed before I wrote the above. If I'm understanding it correctly (this seems to be GNU sed and I can't test it since none of my sed's support the \+ sequence), this already squeezes multiple pluses into a single space (nothing in the original post indicates that this is desirable, but perhaps it is). If that's the case, then field splitting won't affect the spaces inserted by sed. However, I'll leave my post intact as it does contain some useful information even if most of it mistakenly assumes that your sed could generate multiple spaces from multiple pluses.

Woops and regards,
Alister