Quote:
Originally Posted by itmozart
I'd want to encrypt some files with GPG, named, as example "1.txt" and "2.txt".
So far so good, I can use something like:
Code:
find /tmp -name '*.txt' | xargs -I {} gpg -r test@test.com --output {}.enc --encrypt {}
Problem is, that I want to add the date to the filename.
Now, with a quite awkward stat+sed I can generate the filename (excerpt):
Code:
stat -c%n%y {} | sed -r 's/(.*).txt(\w+)-(\w+)-(\w+).*/\1_\2\3\4.txt/'
(note: the '.' in '.txt' is inappropriate but acceptable)
How can I incorporate this last statement as output file name in the find/xargs/gpg output parameter?
If I do something like:
Code:
find /tmp -name '*.txt' | xargs -I {} gpg -r test@test.com --output $(stat -c%n%y {} | sed -r 's/(.*).txt(\w+)-(\w+)-(\w+).*/\1_\2\3\4.txt/') --encrypt {}
The $() inputs the {} literally.
This won't work either:
find /tmp -name '*.txt' | xargs -I {} sh -c "cat {} | gpg -r test@test.com > $(stat -c%n%y {} | sed -r 's/(.*).txt(\w+)-(\w+)-(\w+).*/\1_\2\3\4.txt/')"
Is there a simple[r] oneliner for doing this operation?
Thanks!
Saverio
|
You know, writing scripts should not be an obfucscation contest. Maybe it would be better to stop trying to see whether any problem can be solved using a long, incomprehensible command line. Please reconsider, open a script file and type some clear, comprehensible instructions:
Code:
path="/path/of/interest"
find $path | egrep "\.txt$" | while read inpath
do
date=`date`
date=${date// /_}
outpath="${inpath//.txt}_${date}.enc"
gpg --encrypt-files $inpath --recipient test@test.com --output $outpath
done
Notice that your one-liner, once it actually worked, would be longer than this formal, transparent, easily understood, solution to your problem.
And please understand that the ultimate victim of miraculous one-liners is ... you, six months from now, when you have to try to decipher what the one-liner actually does.
I will never understand why people insist on using "xargs" and then can't understand why it won't give them what they want. The method I posted above takes longer to
run (because it creates a separate process for each file), but overall it's faster
because it saves development time.
One more comment. In the future, when parallel processing is fully mature, methods like this (that spawn one process per file) will actually run
faster than the alternatives.