Re:Four features that justify a new Unix shell
by zimpenfish on Friday October 23, 2020 @10:33PM
(#24876462)
If I've not wildly misunderstood what you're doing with that line (and apologies if I have), could you not just stick `-printf '%f\n'` on the end of the `find` command?
(By definition, since you're looking for `.ogg` files, everything `find` finds will have a path that ends in a three letter extension.)
Re:Four features that justify a new Unix shell
by esaym on Friday October 23, 2020 @11:55PM
(#24876819)
Ah, that is a good one! I've never even messed with the -prinf options.
Re:Four features that justify a new Unix shell
by zimpenfish on Saturday October 24, 2020 @06:18AM
(#24878206)
It's one of those things that's immensely helpful but difficult to discover organically, I think, since a lot of people will go "find outputs this, now I pipeline to transform that, this is The Unix Way" and never realise that `find` can do a bunch of transforms for you for free.
Re:Four features that justify a new Unix shell
by sergeykish on Saturday October 24, 2020 @07:55AM
(#24878623)
It would be simpler (and match "everything after the last '/'") with
perl -nle 'if( $_ =~ /([^\/]+)$/) { print "$1"}'
And it allows ",ogg" (dot not escaped so it is not extension), thankfully find provides /\.ogg$/
Re:Four features that justify a new Unix shell
by esaym on Saturday October 24, 2020 @12:58PM
(#24880408)
Space was because HN uses it as italics and I don't know the escape. And yes there are cleaner ways, but the point was a real world example of having something not work out in pure shell but yet quickly barfing out something working with perl. And yes, looks like I didn't escape the dot, funny!
Re:Four features that justify a new Unix shell
by sergeykish on Sunday October 25, 2020 @08:58AM
(#24885954)
Got it. Sure, I like one liners and I like piping. Ruby is strongly influenced by Perl:
$ find . -iname '*.ogg' | ruby -nle 'puts $1 if $_ =~ /\/([\w-]+\.\w\w\w)$/'
Re:Four features that justify a new Unix shell
by gray_-_wolf on Saturday October 24, 2020 @07:09PM
(#24882626)
Or, in actual posix compatible way:
find /tmp/test -type f -iname '*.ogg' -exec sh -c 'for f; do printf "%s\n" "${f##*/}"; done' - {} +
Re:Four features that justify a new Unix shell
by high_priest on Friday October 23, 2020 @09:51PM
(#24876267)
Why am I not surprised that the PERL part could be solved with bash in the same space. Why are you so eager to use lang on top of lang, in such simple cases?
Re:Four features that justify a new Unix shell
by esaym on Friday October 23, 2020 @10:07PM
(#24876331)
Feel free to demonstrate. Take a long path with nasty characters and give me the ending file name. I want "track1.mp3" returned from:
/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3
Re:Four features that justify a new Unix shell
by zimpenfish on Friday October 23, 2020 @10:38PM
(#24876493)
If you have that in a variable, which you presumably would if you're reading them one at a time, you can use "remove longest matching prefix" substitution.
$ i="/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3"
$ echo "${i##*/}"
track1.mp3
Re:Four features that justify a new Unix shell
by sergeykish on Saturday October 24, 2020 @08:22AM
(#24878727)
This part is really cryptic, I would prefer
$ function remove_longest_matching_prefix () { echo "${1##$2}"; }
$ remove_longest_matching_prefix "$i" '*/'
track1.mp3
Re:Four features that justify a new Unix shell
by Jare on Saturday October 24, 2020 @06:46AM
(#24878315)
You still get +1 for providing a pointer to the explanation while remaining clear and succinct.
Re:Four features that justify a new Unix shell
by AareyBaba on Friday October 23, 2020 @10:28PM
(#24876436)
$ basename "/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3"
track1.mp3
It is not that hard either (unless perl is completely foreign to you).
Ironically just today I wrote a python script (using concurrent.futures) to batch re-encode 10gb of mp3 podcasts into 3gb of opus files to save space. Before I deleted the old mp3's, I did a quick file count of mp3 and opus files only to have 5 extra opus files... I beat my head really good trying to glue a bunch of bash stuff together but I could not find where the 5 extra opus files were coming from.
I defected back to perl. All I needed was an alphabetical list of all the files (there were many sub-directories), perfect for a little perl oneliner:
I did the same thing for * .mp3 files and then diffed the two files. I quickly noticed the extra 5 opus files were from me doing test encodes a couple of weeks ago that I forgot about.Sure it looks hideous, but the explanation is easy: for 'perl -nle', the 'l' means process each line from stdin individually, the 'n' means no auto printing of the line, and the 'e' is basically the perl 'one liner' mode. Either way, each line comes in and is stored in '$_', I use a capturing regex to grab the file name without parent directory names, basically everything after the last '/' in a path that ends with a three letter extension (\w\w\w). The "captured" part of the regex ends up in '$1'. Also see 'perldoc run' for all the runtime one liner options.