Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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).
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.
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?
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.
A working script now, but another annoyance has cropped up
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.
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.
#!/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.
Don't take the answer beyond the scope of the question, please.
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.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.