How do you match everything after an element using regex? I want to rename some files that follow the scheme "ShowName.S01E*.Episode.Title.mp4" and turn them into "SN.S01E*.mp4" where the * is the episode number. So far I have this dry-run using echo:
for file in "$1"
do
new="${file/ShowName/Sn}"
new="${new/(?
Other urls found in this thread:
cyberciti.biz
twitter.com
Din.t bother and use the prename utility which allows renaming in see style.
rename ''s/Richard Stallman/RMS/' *.jpg
>see
sed style (actually it's Perl regex)
Thanks, the lookbehind works with that. Must be because of the perl regex mentioned
Is there some way to get this nice, more powerful perl regex to be used with normal bash string manipulation?
regex101.com
As others said, use the right tool for the job.
As for your original question:
>"$1"
did you mean "$@", or how are you invoking your script?
$1
I modeled it after a previous script I made that worked as I wanted:
#!/usr/bin/env bash
# Usage: manytomp4 *.avi
for file in "$1"
do
ffmpeg -i "$file" -f mp4 -vcodec libx264 -preset fast -profile:v main -acodec aac "$file.mp4" -hide_banner
notify-send "$file done transcoding"
done
notify-send "all done transcoding"
uh read the man page. parameter substitution does not take a regular expression.
${parameter/pattern/string}
Pattern substitution. The pattern is expanded to produce a pattern just as in pathname expansion. Parameter is expanded and the longest match of pattern
against its value is replaced with string. If pattern begins with /, all matches of pattern are replaced with string. Normally only the first match is
replaced. If pattern begins with #, it must match at the beginning of the expanded value of parameter. If pattern begins with %, it must match at the end
of the expanded value of parameter. If string is null, matches of pattern are deleted and the / following pattern may be omitted. If the nocasematch shell
option is enabled, the match is performed without regard to the case of alphabetic characters. If parameter is @ or *, the substitution operation is applied
to each positional parameter in turn, and the expansion is the resultant list. If parameter is an array variable subscripted with @ or *, the substitution
operation is applied to each member of the array in turn, and the expansion is the resultant list.
for file; do
you don't need to use `in` if you want to iterate over positional args ${@:0:1} -> ${@: -1}
really wish people would bother to actually fucking learn the language. you people seriously are tarded.
I am trying to learn the language. People learn best by doing, so I'm trying to use it in ways that are useful for me. No need to get frustrated and impatient.
$1 is the first positional argument.
Here's how this works:
$ cat shit.sh
#!/usr/bin/env bash
echo dolla-1 is $1
echo dolla-2 is $2
echo dolla-at is $@
$ touch tits butt vaganus
$ ./shit.sh *
dolla-1 is butt
dolla-2 is shit.sh
dolla-at is butt shit.sh tits vaganus
Thing is when you say './shit.sh *', bash, *before* starting shit.sh, expands '*' into 'butt shit.sh tits vaganus'.
It then starts shit.sh and passes it 3 arguments.
Thus, try using 'for file in "$@"'. The double quotes may or may not be necessary, bash quoting is a clusterfuck when you start allowing chars that need to be escaped in your filenames.
>passes it 3 arguments
should've been 4, obviously
Also, skim this if you're interested:
cyberciti.biz
Thanks, that is very helpful.
Not sure why "$1" worked for me in the past, but I'll use "$@" from now on for expansion.
>retards still saying for file in "$@"
literally just for whatever; do
jesus
>muh implicit is better than explicit
shoo shoo, perl goblin
literally ok. but it's an immediately obvious way to spot retards who don't know bash grammars.
>expecting anyone who respects their time to learn your arcane "made all the possible mistakes" snowflake grammar
srsly tho, 'for file; do' is perl-level retarded in terms of readability, and 'for file in $@' is literally preferable in every possible way
Just because you can, doesn't mean you should.
bash is fucking garbage just like pozzix defined "sh" but that's not an excuse to not learn a tool that's sadly used in many places where it probably shouldn't.
still no argument against 'for file in $@' tho
I say we should aim to not learn bash, as much as possible, as a form of protest.
If everyone's doing a decent job of using this pile of hacks, there's less incentive to introduce more sane alternatives.
bash will literally expand $@ in the first case and in the second it's not doing retarded extra work by expanding all args before parsing your for loop.
for the sake of wasting time.
#!/bin/bash
fun() {
for arg; do printf '%s\n' "$arg"; done
} >/dev/null
fun2() {
for arg in "$@"; do printf '%s\n' "$arg"; done
} >/dev/null
time fun {1..10000}
time fun2 {1..10000}
>first case
>second
which is what?
how does that prevent it from being god-awful and worst-practice in terms of readability?
$ ./test.sh
real 0m0.244s
user 0m0.237s
sys 0m0.007s
real 0m0.226s
user 0m0.222s
sys 0m0.004s
it's not unreadable if you know how the language works.
the same was said by perl advocates, but hopefully we've learned history, instead of being doomed to repeat it, right?
I'm trying to iterate over some filenames, and extract the image dimensions from running the file command on each. For some reason "file" sometimes has the dimensions as '800x600' and sometimes '800 x 600'. Can someone tell me why this line isn't working?
/usr/bin/file "$filename" | grep -o '[0-9]*\s?x\s?[0-9]*'
If I get rid of the question mark in the regex I get the dimensions that are like '800 x 600'. I want that space to be optional though, but if I do that, no dimensions are returned. Why isn't the optional token working in this case?
The functionality works as I need if I replace '?' with '*', but I'm just wondering why the optional token wasn't working.
use grep in ERE mode for ? qualifier
Thanks user, that works now
Why would one not want to use grep in ERE or Perl mode? Why aren't either the default?
I think you can just backslash escape the question marks too. Same for plusses.
Yeah, came across that while googling about ERE. Would be annoying to have to escape even more stuff
something something legacy retarded bullshit. if it makes you feel better, there isn't a performance cost to using -E in GNU grep. it's the same engine, but the parser just handles escapes different and has more qualifiers.
oops. ya i forgot how gnu grep does that. like I just said. BRE and ERE mode in GNU grep are basically the same, the differences are like magic modes in vim. mostly escaping related.
I think I'm just going to add alias grep='grep -E' to my .bashrc anyway
just remember to note that when scripting.
Yeah, I figure I'll explicitly do grep -E in scripts and just grep when I'm just entering a command
bump for more comfy bash discussion