bash script suddenly stopped working

L_Carver · 05-27-2017, 08:14 PM

Code:

#!/bin/bash -i
SAVEIFS=$IFS
IFS=$"\n\b"


picc=( "$1" )
date0=$(stat -c %y "$${picc[0]}" 2>/dev/null | /usr/bin/cut -d. -f1)
dart=${date0//-/}
dart=${dart/ /}
dart2=${dart/:/}
dart=${dart2/:/.}
echo -e "$date0\t$dart"
exit 1
echo "Please enter dimensions (HxV) for ${picc[0]}."
read -e dims
/usr/bin/mogrify -quality 96 -filter lanczos -resize "$dims+0+0!" "${picc[0]}"
/usr/bin/touch -t "$dart" "${picc[0]}"
echo -e "Picture file ${picc[0]} resized to $dims and mod date restored.)"
IFS=$SAVEIFS

It used to apply the "dart" value with touch -t error-free, now it returns an invalid date format error.

I ran Shellcheck on it, corrected a few things it pointed out, and it still gives the error. I suppose Shellcheck doesn;t check for what will work with touch -t in all circumstances.

I'd RTFM, except i find the GNU man-page less than fully informative (haven't read the coreutils info part in a long while, though).

Carver

scasey · 05-27-2017, 08:21 PM

Have you tried adding

Code:

echo "$dart"

to see what's in there that touch thinks is invalid?
And/or show us what you're passing to the script to populate picc

ntubski · 05-27-2017, 09:58 PM

Code:

IFS=$"\n\b"

I don't think this is specifically your problem, but shouldn't that be

Code:

IFS=$'\n\b'

(also wondering why you're putting \b in IFS)

Reference:
ANSI-C Quoting
Locale-Specific Translation

L_Carver · 05-27-2017, 11:37 PM

Quote:

Originally Posted by ntubski

(also wondering why you're putting \b in IFS)

I've tried it without the \b, and in earlier versions of bash it didn't work correctly. I just had bash upgraded from the repos, so I think I may try excluding it again, As for going with single quotes on the

Code:

IFS=$"\n\b"

I may try that, too. Double-quotes with me are reflections of my Cygwin days, and I usually "break" a bash install with them (as with mv and renaming single files) by using them.

Carver

L_Carver · 05-27-2017, 11:41 PM

Quote:

Originally Posted by scasey

Have you tried adding

Code:

echo "$dart"

to see what's in there that touch thinks is invalid?
And/or show us what you're passing to the script to populate picc

Line 12 has an "echo $dart."

And picc is usually it's the name of a JPEG file, such as 310_1000.jpg.

Carver

ntubski · 05-27-2017, 11:47 PM

Quote:

Originally Posted by L_Carver

Line 12 has an "echo $dart."

Perhaps you'd like to share the output with us?

L_Carver · 05-27-2017, 11:54 PM

Quote:

Originally Posted by ntubski

Perhaps you'd like to share the output with us?

Sure thing. Next post on this thread, I'll show one.

Side topic: an irony is that the "touch is now broken" script is the one I asked for trimming-down advice here.

Carver

scasey · 05-28-2017, 12:30 AM

Quote:

Originally Posted by L_Carver

Line 12 has an "echo $dart."

Oops!

L_Carver · 05-30-2017, 05:47 PM

I ran the script, commenting out any "exit0's" I was using to test where the date variable values go missing, and it did not return a touch error.

Here is the script I ran:

Code:

#!/bin/bash -i
SAVEIFS=$IFS
IFS=$'\n'


picc="$1"
date0=$(stat -c %y "$picc" 2>/dev/null | /usr/bin/cut -d. -f1)
echo $date0
dart=${date0//-/}
dart=${dart/ /}
dart2=${dart/:/}
dart=${dart2/:/.}
echo -e "$dart"
#exit 1
echo "Please enter dimensions (HxV) for ${picc[0]}."
read -e dims
/usr/bin/mogrify -quality 96 -filter lanczos -resize "$dims+0+0!" "${picc[0]}"
/usr/bin/touch -t "$dart" "${picc[0]}"
echo -e "Picture file ${picc[0]} resized to $dims and mod date restored.)"
IFS=$SAVEIFS

Which looks about the same as the last one I posted, doesn't it? This one may have a few corrections suggested by Shellcheck and the folks here, but on the whole it's the same script.

So the thing that makes me want to scratch my head is: why did it suddenly start working again?

Carver

pan64 · 05-31-2017, 03:24 AM

Quote:

Originally Posted by L_Carver

Which looks about the same as the last one I posted, doesn't it? This one may have a few corrections suggested by Shellcheck and the folks here, but on the whole it's the same script.

So the thing that makes me want to scratch my head is: why did it suddenly start working again?

Probably those small corrections mean some real functional changes (as I already told you: a $, a { } or () or \ may significantly change the program flow...)

But you forgot to explain what did you modify exactly, so noone can tell you exactly why.

L_Carver · 06-10-2017, 05:05 AM

Code:

#!/bin/bash -i
SAVEIFS=$IFS
IFS=$"\n\b"

picc=$1
if [ -f "$picc" ]; then
if [ ! -z "$TDATE" ]; then
 touch dummy
 touch -t "$TDATE" dummy
 echo "The empty file, dummy, was dated as follows"
 stat -c %y dummy
 touch -r "dummy" "$picc"
 /usr/bin/shred -u dummy
fi
fi
IFS=$SAVEIFS

It works, and in spite of what I said in a previous post about keeping noclobber off, I'd really rather delete the file dummy after the 'touch -r' command copies its date stamp to the target file. It seems now to be unable to do this. I've tried "rm," "/usr/bin/rm,' even invoked shred, and it has made no difference. Then I had the (dumb?) idea to write a script specifically to delete the 'dummy' file from my working directory if it found one. And when I invoked it from the above script, it still didn't work.

Carver

pan64 · 06-10-2017, 12:51 PM

did you try set -xv? did you check if rm/shred was really executed?
Again you did not post what you really tried
the -i in the first line is definitely not required.

scasey · 06-10-2017, 01:56 PM

Quote:

Originally Posted by L_Carver

Code:

#!/bin/bash -i
SAVEIFS=$IFS
IFS=$"\n\b"

picc=$1
if [ -f "$picc" ]; then
##if [ ! -z "$TDATE" ]; then
## touch dummy
## touch -t "$TDATE" dummy
## echo "The empty file, dummy, was dated as follows"
## stat -c %y dummy
## touch -r "dummy" "$picc"
## /usr/bin/shred -u dummy
##fi
   touch "$picc"
fi
IFS=$SAVEIFS

It works, and in spite of what I said in a previous post about keeping noclobber off, I'd really rather delete the file dummy after the 'touch -r' command copies its date stamp to the target file. It seems now to be unable to do this. I've tried "rm," "/usr/bin/rm,' even invoked shred, and it has made no difference. Then I had the (dumb?) idea to write a script specifically to delete the 'dummy' file from my working directory if it found one. And when I invoked it from the above script, it still didn't work.

Carver

Again, I feel compelled to ask: Why use dummy and touch -r at all?
See the edited script above...I commented out (and highlighted) the lines I'm saying are not needed to accomplish the task and added one new line. This will have the effect of setting the timestamp on the file named in $picc to "now", which is what the original script is doing [I'm unable to test this, however, and leave it to the OP to try it out].
Needless to say, that makes the last concern about removing the file dummy moot.

L_Carver · 06-11-2017, 03:10 AM

Quote:

Originally Posted by scasey

Again, I feel compelled to ask: Why use dummy and touch -r at all?

I am trying to preserve the file's original modified time. Logically, the various executables in the ImageMagick 'suite,' for instance, change it when you use them on an image file. I want to return the dates I get on each file (server-side modified dates) because, frankly, I hate seeing 2017 in a file date. That's why I used (at someone else's suggestion) the dummy file and touch -r. The last thing I'd want to do is a simple "touch" since that would as likely as not (by the definition of 'touch,' that likelihood is high) set the file's modification date to a date after January 1 2017 and before December 31 2017, which I absolutely do not want. On those occasions when I do download a file with a 2017 mod date, I go searching for another file that has one from a previous year to "borrow" its date for the "newer" (not always really new, because chances are good I've seen it before this year) picture file.

I simply wanted to know why the script was not creating, using, then deleting the dummy file when I instructed it to. I hardly expected a re-analysis of the whole script. I said it worked to my satisfaction except for this one small new issue, which I thought was a glitch in my coding, and still think so.

Carver

L_Carver · 06-11-2017, 03:17 AM

Quote:

Originally Posted by pan64

did you try set -xv? did you check if rm/shred was really executed?
Again you did not post what you really tried
the -i in the first line is definitely not required.

I'm so perfectly UNimpressed by bash 4's so-called error checking I'm disinclined ever to use set -xv again. And every line I used (rm, shred) to delete 'dummy' left it there for the second script to take care of. Lately I've been resorting to this as a workaround:

Code:

autotouch foo.jpg && nodummy

I don't want that second bit to be necessary. I don't think it impossible to delete the dummy file from within the autotouch script once it's been created and used (in the touch -r command).

Carver