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@xxxxxxxxxxxxx>
> 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.
