Dolphin service menu help: preserve file timestamp

[Duncan]

Dotan Cohen posted on Sat, 18 Dec 2010 00:51:24 +0200 as excerpted:

> On Fri, Dec 17, 2010 at 20:30, Alex Schuster <wonko at wonkology.org>
> wrote:
>> Yes. Something like this (untested):
>>
>> #!/bin/bash
>>
>> while (( $# ))
>> do
>>        date=$( ls -l --full-time "$1" |
>>                awk '{ print $6" "$7 }' | sed 's/.00000*//g' )
>>        iconv -f CP1255 -t UTF-8 "$1" > "$1-utf8" touch -d "$date"
>>        "$1-utf8"
>>        shift
>> done
>>
>>
> Thanks. I have some googling to do, but I'll ask anyway:
> 
> 
>> while (( $# ))
> Does this mean to go through each CLI argument, something like foreach?

You have the idea, but not the implementation...

Bash's $# is a special built-in var that simply returns the number of 
parameters (each of which is referenced by its position using $d, where 
"d" is a digital number.  While continues looping /while/ its condition is 
true.  (Shell true, <> 0.)

> What does the "shift" line do?

Shift throws away the left-most argument and shifts others up one 
position.  Combined with that while, the effect is to loop thru the 
parameters, removing the left-most one and returning the others "shifted" 
by one position each time, until there's none left.

You'll note the multiple-use of $1 below, referring to the left-most 
parameter, within the loop, so the full implementation loops repeatedly, 
treating only the left-most positional parameter each time, then throwing 
it away, /while/ there's positional parameters left.

>>        date=$( ls -l --full-time "$1" |
>>                awk '{ print $6" "$7 }' | sed 's/.00000*//g' )
> This is pure genius, I was wondering exactly how difficult it would be
> to get this info into a variable in the format that touch would use.

For whatever reason I've never really gotten my head around awk.  I 
intellectually know what it does.  I just tend to find other ways of doing 
it instead, using pipes of cut/grep/sed/head/tail and/or shell pattern 
matching constructs such as ${var#pattern} as necessary.  Either way 
works, and on single commands or loops repeated a couple dozen times or 
so, coming up with the code in the first place is likely to be the 
bottleneck, but once the loop reps reach triple digits, performance of the 
loop itself begins to matter and each command in a pipe or other compound 
counts, so where awk can be used to avoid strings of several commands, 
it's likely more efficient.  Similarly, bash-internal commands will be 
more efficient than invoking an external program, since an external 
invocation comes with system overhead.  That and the fact that if you're 
running shell you /know/ it's available, but there's always a small chance 
external commands won't be (as can be the case in early boot-scripts), are 
both reasons you often see long strings of bash internals, pattern 
matching based variable manipulation and the like.

The last thought actually helps to explain why I've never seemed to get my 
head around awk in practice, as well, given that like many I suppose, I 
first learned practical shell scripting by studying initscripts.  FWIW, 
this is one negative of the fancy new parallel fast-boot init 
replacements, as they tend to replace reasonably transparent and easily 
learned shell scripts with the sources out there for a budding sysadmin to 
explore, with far more opaque compiled programs with sources hidden away, 
separate from their binaries and often in -dev packages not installed by 
default.  As computers get more complex, it's surely a reoccurring theme 
that each generation bemoans the loss of the "to the metal" sysadmin 
skills in the generations coming after, but knowing that doesn't make it 
any less difficult to watch as relatively transparent shell scripting gets 
replaced by far more opaque and less discoverable boot methods, with 
admins, if they're good, only knowing how to modify a few config 
parameters, instead of being able to reshape the entire boot process if 
they need to.  But as I said, I'm sure a generation or two back they were 
bemoaning the newfangled shell scripts in the same way, as admins no 
longer knew how to type in the individual boot commands one at a time, and 
before that, bemoaning the newfangled boot commands, as admins no longer 
could flip raw hardware switches to create binary bootstrapping code in 
real time.   But that realization still doesn't make it easy to watch as 
it happens, or the combined pain/pride of the realization that one is now 
officially an "old fart" as a result of having those feelings, knowing 
it's progress, but somehow wishing it didn't have to happen that way at 
the same time. =:^(

OK, so that wandered "just a bit" OT... =:^)

>> If you want to replace the files, you could proabaly use recode, which
>> keeps the time unless told otherwise:
>> Exec=recode CP1255..utf8 %f
>>
> Actually, this is _exactly_ what I need. Thanks!

Beats me.  I know shell reasonably well but (thankfully) don't have to 
deal with l10n issues that much, here, so don't know much about them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.