Oh, well I know why Python behaves like this -- it's for the same reason most languages do! The variables uses by code in a function should be the ones that the programmer who writes the function knows about and can reason about when they write the function, not the ones the programmer who writes the code that uses the function knows about and can reason about when they write the code that uses the function (even if they are the same person, as is sometimes the case).

In Bash, the real reason this hasn't been a problem for me--and why I haven't noticed the behavior before--is that I don't write big or complicated Bash scripts (except sometimes for fun). But this means that in Bash, when one writess a function f() that calls a function g(), one must never introduce a local variable in f() that has the same name as a global (or less local) variable that the implementation of g() relies on.

That causes all shell functions' implementations to be tightly and usually unintentionally coupled to one another, if they use any variables other than local variables that they introduce.

yes as far i understood that is that there are no explicit scopes in bash

I'm not sure what you mean by that. local variables are local... just not in the way I thought. If you mean there is no lexical scoping of variables in Bash, then yes, apparently that is the case, though I had wrongly thought local was lexically scoped until recently.

In general, Python behavior of scoping lexically rather than dynamically is what I expect; it's similar to other languages with local variables (some of which I'm proficient in, and others--like Scheme--that I'm not, but have used) including C, C++, Java, C#, F#, QBasic (in SUBs and FUNCTIONs), VBA, VB .NET, Ruby, Scheme, JavaScript with let and const (and var, though that's function scoped, like locals in Python, not block scoped as in other languages), and my variables in Perl.

yeah and thats good that it is like it is, so you can have a fix interface for the users of your classes/functions and can change the inside of classes functions as you need, this is why using public variables in classes is being frowned upon

Interestingly, the local keyword in Perl does declare dynamically scope variables. So my $/ = "\0" doesn't change what functions like readline(which gets called from constructs like <>) uses as the input record separator, but local $/ = "\0" does succeed at changing it from a newline to a null character, and is the generally recommended way to do so.

I had thought Perl was the only language I ever used that offered dynamic scoping (with local), but it turns out that I was using dynamic scoping in Bash all along!

@Videonauth Well, public data members of classes still don't produce the weird situation (to me, it is weird) that you get with dynamic scoping in Bash, where the calling context changes what variable is accessed in the body of a function, even when the same function implementation is being used.

One thing I had not expected about Python, when I first started using it, is that local variables are scoped to the function in which they are introduced (like with var in JavaScript), rather than to the block in which they are introduced (like in most of the languages I listed and--I think--in most languages that have both a notion of blocks and a notion of local variables). This is still far less alarming to me than how Bash local variables are dynamically scoped, though.

well i basically came from C++ where the scopes are very strict in terms of pure existence of variables

variables are only existent in the {} block they are written in

except you pass variable copys or pointers around

Yes.

only if they are declared outside any block they count as globals

Yeah, if they're not in a block because they have global scope or file scope, then they are accessible inside blocks.

yep some people even deem this bad coding practice, I for myself use them if they are really needed

but only then

c and c++ are the harshest enviroments to code in, but when you once really get the hang of it it gets more and more clear

and the nowadays compilers are pretty good i have to say, you wont get any optimization by directly injecting assembler to a c or c++ programm in most cases

From C++11 on, you can write lambdas that capture local variables into them, though it does not happen unless you ask for it. That is, if you write the empty capture list [], nothing is captured. If you want to capture everything that your lambda would use, you would have to write [=] (to capture by value) or [&] (to capture by reference). This is dissimilar to closures in languages like Python and C# where capturing is always automatic.

but since i got into linux i have fallen in love with python and neglected c++ mostly

i love python for the integer range it can display safely

sure ok 64 bit long long is quite a big number but when you for example calculate factorials or something big 64 bit is by far not enough to save the numbers in

but as c and c++ python suffers the same floating point errors as all programming languages do

Yeah, I wish C++ had an std::bigint. Especially now that stuff like a filesystem library is finally standardized for C++, it feels like there should be something in the C++ standard library like System.Numerics.BigInteger (for .NET/Mono languages like C#), java.math.BigInteger in Java, int in Python 3, long in Python 2 (which operations on regular int produce automatically when necessary), Integer in Ruby, Math::BigInt in Perl, ...

yep

I do recommend new C++, though. In my opinion, C++11 and later are much, much nicer than C++03 and earlier.

indeed they are, but they are as well more confusing if you ask me

especially in the typedef part

templates i mean

like classes the templates are meanwhile overused

and dont you dare to use functions instead of classes lol all people will pounce on you if you show your code :)

but i think thats a problem generated by universities

they are so eager to have people use classes and everything is an object mentality that they forget simple functions when it comes to solving problems

dont get me wrong, classes are nice, but i cant count how often i have seen classes with only two single functions in it and of of them was init()

and up to that they have been singletons

there was a talk on youtube i found very interesting about that

well I'm actually pretty tired (not slept since monday) and run into wall with my python code for my source-list-tool, guess I'm laying down and have some rest. BTW this python script is constantly growing as i have new ideas to include in that. So the small idea started out to become a ful grown project I'm working on

^@EliahKagan

laters

@Videonauth Have you observed C++ programmers insisting that OOP techniques be used when other approaches are at least as good? It is fundamental to the design of C++ that you shouldn't need to use OOP, that you can make functions that aren't related to a class, as well as functions that are related to a class but that are not methods of that class (because of argument-dependent lookup). I think Java is designed to push programmers to use (its vision of) OOP, but that C++ is almost the opposite.

steve-yegge.blogspot.com/2006/03/…

I don't entirely agree with what Yegge said there, because I think it has been ingeniously demonstrated that culture has a lot to do with it, not just language features. Also, whether or not C and C++ has first-class functions depends on what one means by "first class functions," but I doubt most programmers from languages like Python, JavaScript, or Scheme would say so.

Furthermore, there's a good argument to be made that Java 8 introduced exactly the features that Yegge was calling for, since it introduces lambda expressions, which mostly let programmers avoid thinking about functional problems in OOP terms in cases when it's not actually useful to do so, and streams, which (together with lambda expressions) facilitate a functional style of programming.

They carry some common benefits of functional programming, like parallelizability and avoiding pointlessly making verbs into nouns. They are comparable, in some ways, to LINQ in the .NET Framework and Mono (and, in particular, to the style of programming facilitated by LINQ extension methods in C# and VB .NET). But I agree wholeheardedly with that blog post by Steve Yegge, at least if I interpret it as a critique of the OOP orthodoxy that one often encounters in the context of Java programming.

I edited my post @Videonauth - thanks again for pointing out the colon issue.

@EliahKagan yeah problem is that most university classes start with java in the first semesters and then change to c++ and nobody telling them that functions are as fine. and yes i have had it happen on many many occasions that people tried to push me into using classes where no clas was needed at all

@Zanna youre very welcome, but its good to know that tar can connect to ther hosts :) never seen a compression programm having network code :)

yeah

one of my favorite songs

Sting is good

I feel like an alien everywhere I go, guess its my battlehymn :)

wait so . does not stand for every character in range?

in a character class, it's just a .. So no need to escape it... I noticed that, but, took me a while to confirm it

Just mentioning because of your comment

@Zanna Yes I removed it after you mentioned your own comment.

still +1

thanks :) hopefully I removed the misleading part

well iirc i have read in my regex book that . is every printable character, so that must be sed specific

hmm I think it's in any regex flavor, but only in a character class

grep uses . as well as every printable character

heck you can even use silly things like that (warning dangerous action) apt remove ... which seems to fetch really everything :P

:)

its maybe to prevent mountainrange

you know what i mean?

@Videonauth hmm?

I bet @EliahKagan can shed some light here maybe later?.

@Videonauth yes, it uses BRE by default I think, like sed, and in BRE . is any character, but in a character class, it is literal

what are you showing in that image?

thats regex find&replace in pycharm

and the search term for that regex is simply .

As far as I know, . in a character class is treated literally in all regex dialects.

@Videonauth oh I see! Sorry. But that's not using a character class

i bet that not everything green you seeing is a .

yep thats pure regex

Outside of a character class, it is a metacharacter.

@EliahKagan yep, i just saw as i put [.] it only fetches the dots

@Videonauth Interestingly, which characters . matches (when it's outside a character class) differs between dialects, and for some dialects it's configurable. But as far as I know, this mainly concerns whether or not line terminators are matched, so it typically doesn't make a difference for text that is being matched line-by-line, as with grep and sed. Many regex dialects support a "single line" option that lets . match newlines, which it otherwise wouldn't. For example, in Python 3.6.1:

>>> import re
>>> re.findall(r'.+', 'foo\nbar')
['foo', 'bar']
>>> re.findall(r'(?s).+', 'foo\nbar')
['foo\nbar']

afaik . matches \n in sed when it's been read into the pattern space by N

That's a good point. sed can process text that is taken to be more than one record, and . still matches the record separator, even in the default case that it is a newline. As you say, with N:

$ printf 'foo\nbar\n' | sed 'N; s/foo.bar/MATCHED/'
MATCHED

$ echo -e 'I have put a\nnewline in it!' | sed 'N; s/.newline/ space/'
I have put a space in it!

@Videonauth Did it say what non-printable characters does . not match in sed? At least in GNU sed 4.2.2 in Ubuntu 16.04, . matches the null character:

$ printf 'foo\0bar\n' | sed 's/./[\0]/g' | cat -v
[f][o][o][^@][b][a][r]

@EliahKagan oh you already tested it :)

acquire habit of generally using printf instead of echo >> TODO

@EliahKagan That example is sort of confusing, because it looks like \0 in the sed script means a null character (it doesn't, it's a backreference to group 0, which is the whole match), and because it looks like [ ] indicate a character class, which they don't, because they're in the replacement string. Here's a less confusing example of how . matches a null character:

$ printf 'foo\0bar\n' | sed -r 's/(.)/<\1>/g' | cat -v
<f><o><o><^@><b><a><r>

why don't you use & for the whole match?

have I misunderstood what you wanted?

No, you haven't misunderstood. That works fine.

but TIL that \0 is the whole match!

$ printf 'foo\0bar\n' | sed 's/./[&]/g' | cat -v
[f][o][o][^@][b][a][r]

clearly . matches the null character in sed :)

The honest answer for why I didn't is that TIL & is the whole match!

:D it's a good day

:)

I might not use that much, though. Group 0 is the whole match in every regex engine, as far as I know, and \0 fits well with the \1, \2, etc., notation. In Perl, I do use $& (not &) for the whole match. I didn't know it came from & in sed.

$ printf 'foo\0bar\n' | perl -wpe 's/./[$&]/g' | cat -v
[f][o][o][^@][b][a][r]

IIRC $0 is the whole record in awk, so \0 kind of resonates with that

maybe & in sed comes from $& in Perl...

Well sed is way older, isn't it?

Oh I have no idea, I know almost nothing about this history

Perl allows \1, \2, etc. to be sorta compatible with sed but it recommends against them and issues a warning if warnings are enabled. It does not support \0 for the whole match, because \0 means a null character even in substitution text. In Perl, the recommended way to accesse numbered backreferences is as $1, $2, and so on, rather than \1, \2, and so on. This works in other code after the expression, too, because $1, $2, and so on are special variables.

Ahh yes, I've noticed that rename allows me to use \1 \2 but advises me to use $1 $2 instead (when I am absent minded and default to sedisms when using rename)

rename gives very helpful error & warning messages imo!

Yeah. rename has warnings enabled by default. That's what the -w option does in my perl one-liner, which has the same effect as if all code appeared below use warnings;. But rename enables use strict; as well.

what does use strict do (if you feel like explaining it)?

(I can obviously be less lazy and go and find/figure it out)

Consider this highly contrived use of rename:

rename -n 'my $s = $_; print "[$s]\n"' <<<foo

That prints:

[foo]

However, if you remove my:

Global symbol "$s" requires explicit package name (did you forget to declare "my $s"?) at (user-supplied code).
Global symbol "$s" requires explicit package name (did you forget to declare "my $s"?) at (user-supplied code).

Here's a Perl one-liner that also prints [foo]:

perl -wpe 'chomp; my $s = $_; print "[$s]\n"' <<<foo

Removing my doesn't change it at all.

But:

$ perl -wpe 'use strict; chomp; $s = $_; print "[$s]\n"' <<<foo
Global symbol "$s" requires explicit package name (did you forget to declare "my $s"?) at -e line 1.
Global symbol "$s" requires explicit package name (did you forget to declare "my $s"?) at -e line 1.
Execution of -e aborted due to compilation errors.

Adding back my avoids that error, even with use strict;.

so it refuses to assume things that could be ambiguous?

It prohibits "unsafe constructs," but the main effect is usually that global variables have to be declared.

irrelevantly, what does $_ signify in this context?

In Perl, a variable is global if it is introduced without first being declared to have some other scope. With use strict;, even global variables have to be declared first. Usually when people introduce a new variable that doesn't exist, they mean for it to be a lexically scoped local variable. To declare x, that way, one could write my $x;. Variables in Perl can also be local but dynamically scoped (like I've recently learned locals are in Bash). In Perl, local $x does that.

Or they can be local, lexically scoped to a block, but survive across separate accesses to the block, so they are only initialized once and the value reused in subsequent runs of the block. Most languages call these "static" variables. Perl calls them state variables and you can create them with state $x;.

Or they can be global variables, and you can create them with our $x;. When you do that, $x is still only in scope in the block in which our $x appeared, but the variable it refers to is global.

hmmm

my, local, state, and our are considered operators, I believe. I wrote them as single statements that just introduce the variable, but they can also appear in more complex expressions, like my $x = 3 or my $y = my $x = 3` or (as one might use in an if condition) defined(my $x = some_function()). They also are not limited to scalar variables (the $ sigil means scalar). You will see stuff like my @array and my %hash too.

@Zanna I'm glad you asked! :) That's extremely relevant, including to the operation of rename.

BRB

:)

Are you willing to install reply so you can try out Perl code more easily? reply is the most popular REPL for Perl.

Unlike Bash, where there is only minimal difference between running as a read-evaluate-print loop and just interpreting a script normally, and Python, where there is a bigger difference but the interpreter also functions as a REPL when run with no arguments, and Ruby, where there is a similar difference to Python but the repl is the separate irb executable instead o the regular ruby executable...

in perl, there is no official REPL, though perl can be made to function as a bare-bones REPL by running it with debugging enabled. reply does not come with perl, but it is the most popular REPL for Perl as well as the one I recommend.

oh sure I'll be happy to install it

In Ubuntu, the reply command is provided by the libreply-perl package. I also recommend installing libterm-readline-gnu-perl so the arrow keys do what you want them to do. While you're at it -- and actually even if you don't decide to install reply -- I recommend installing the perl-doc package, which gives you the perldoc command with which you can read Perl documentation. It's sort of like a special man command for Perl-related stuff.

awesome tip!

(why can I never find the shell where my sudo hasn't timed out yet?)

For some things, there's also a manpage of the same name, but lots of Perl modules contain POD markup that perldoc automatically looks up, interprets, and renders. perldoc is mostly controlled like man when you're in it. It also provides handy access to just parts of some of the most popular pages, e.g., perldoc -f my shows just the section of what perldoc perlfunc (or man perlfunc, if you must) would show you that documents my, not the other sections.

@Zanna That sounds like the basis for a question on the main site. I don't mean that you should actually ask, "Why can't I find..." but instead you could ask "How can I find..." It should be possible to read the timestamps and find which ones are unexpired. What I am unsure of is if you can do that without... being root. :)

haha! :)

I think I will ask that question :) but not today

@EliahKagan I installed all three of those packages, but I am sleepy :S

@Zanna $_ is the "current item." When you loop through each element of a list, but you don't specify a loop variable, $_ is used automatically as the loop variable. For example, if you run for my $i (1..5) { say $i } in reply, you'll see:

1
2
3
4
5

There, I used an explicit loop variable ($i).

This does the same thing:

for (1..5) { say $_ }

ah!

Some functions automatically use $_ when no argument is specified. That includes say and print, as well as many others. So this does the same thing (and is the generally preferable way to write it, if you're not explicitly specifying a loop variable):

for (1..5) { say }

nice!

Perl aficionados would be upset if I did not mention that, when you don't specify a loop variable, this form is also permitted:

say for (1..5)

The "body" of the for loop there can basically only be one statement when you do it that way. { say } for (1..5) and { say $_ } for (1..5) do not work. However, you can still write the $_ if you want. This works:

say $_ for (1..5)

hmm

Btw, you can also write foreach instead of for. They mean the same thing in Perl. (There are two forms of the for loop, but they both work with either for or foreach.)

So conceptually that's what $_ means. However, it is written to in some situations other than when it is used automatically as the loop variable in a for loop. And the way perl -n, perl -p use it, it is actually not as the loop variable in a for loop, though it is conceptually similar.

in your first example rename -n 'my $s = $_; print "[$s]\n"' <<<foo, it seems $_ is... the operand

It probably is a for loop variable in rename (i.e., prename and file-rename, since there are actually two separate implementations of the Perl rename utility), but because the behavior of rename is frequently and rightly compared to the behavior of perl -n and perl -p, and because there is a conceptual connection that pins down the more precise meaning of "current item," I should probably say what is going on with $_ in perl -n and perl -p.

@Zanna It's the filename, yes.

But since you said you were tired, maybe it would be better to talk about how $_ gets assigned in perl -n and perl -p another time. (The short answer is that while (<>), which they both use, behaves specially in two ways, and one of them is that the line <> reads gets assigned to $_.)

@Zanna $_ is always the current filename in rename's code argument. When you don't see $_, but you're still using the filename in some way, that means that however you are using it uses $_ automatically.

For example, it is common for the code argument to rename to consist of a single s/// expression:

$ rename -n 's/^/prefix /' <<<$'foo\nbar\nbaz'
rename(foo, prefix foo)
rename(bar, prefix bar)
rename(baz, prefix baz)

There, the code argument is:

s/^/prefix /

but the input was considered to be three files...

When such an expression appears by itself, it is automatically taken to be the right-hand argument of the =~ operator, with $_ as the left-hand argument. That is, s/^/prefix / is actually short for:

$_ =~ s/^/prefix /

$ rename -n '$_ =~ s/^/prefix /' <<<$'foo\nbar\nbaz'
rename(foo, prefix foo)
rename(bar, prefix bar)
rename(baz, prefix baz)

@Zanna Right, it works when they are passed as filename arguments, too. When rename has one or more filename arguments, it doesn't read filenames from standard input. It's silly that I didn't just show it with that syntax.

$ rename -n 's/^/prefix /' foo bar baz
rename(foo, prefix foo)
rename(bar, prefix bar)
rename(baz, prefix baz)

$ rename -n '$_ =~ s/^/prefix /' foo bar baz
rename(foo, prefix foo)
rename(bar, prefix bar)
rename(baz, prefix baz)

rename loops through your filenames. The special $_ variable takes on each filename separately, in separate iterations of the loop. The code argument that you pass to rename (i.e., the "script") is implicitly enclosed inside that loop, so it runs for each filename.

that totally makes sense

Cool! :)

When you pass no filename arguments to rename, it populates its array of filenames from standard input. By default, they are separated by newlines. However, since this is Perl, it is using the input record separator, which you can set to a different value. Unfortunately, that doesn't seem to work right in prename. It does work perfectly in file-rename, though, which is what most users with a Perl rename command in a relatively recent OS have.

but not in Ubuntu 17.10 D:

Well if you install the rename command in 17.10, it's file-rename, right?

The special $/ variable holds the value of the input record separator. If you don't set it explicitly, it's a newline. Thus, this does not work:

$ printf '%s\0' foo bar baz | rename -n 's/^/prefix /'
rename(foobarbaz, prefix foobarbaz)

Piping to cat -v confirms that the problem is that the null characters are being taken as part of a singe filename:

$ printf '%s\0' foo bar baz | rename -n 's/^/prefix /' | cat -v
rename(foo^@bar^@baz, prefix foo^@bar^@baz)

@EliahKagan oh yes... hmm good point, there isn't the other rename. When you run rename before installing rename, command_not_found tells you to install rename, iirc. You don't get a bunch of completely confusing errors because you're trying to use a different command to the one you think you're using.

@EliahKagan got it... but we can set $/ to be \0 I assume... and that could be very useful, because filenames might have newlines...

To be clear, there's a totally separate rename command that isn't related to Perl, which some OSes, like Fedora, use as rename. That command is neither the old prename nor the newer file-rename, both of which are Perl-related. I believe the reason there's no rename command installed by default in 17.10 may be in case users prefer to use that other rename command instead.

That other rename command accepts entirely different syntax and is part of the (upstream) util-linux project; the traditional way to use it in Debian or Ubuntu is to run rename.ul.

oh ok. damn, I see I still don't understand the rename situation

So the distinction I have been making, between prename and file-rename as implementations of rename, is totally separate from the other rename command. Both rename and file-rename accept Perl code that runs for each filename. In most cases, you can use them the same way, without even worrying about which one you have. prename has some bugs, though, that file-rename does not.

The rename command in OSes like Fedora, which in Debian and Ubuntu we can use by running rename.ul, does not work that way at all. It doesn't take Perl code as an argument. You would not likely attempt to use prename or file-rename, end up using rename.ul instead, and have it work.

@Zanna Actually neither do I. It would be good to have a question about this with a comprehensive answer. There's something on Unix & Linux but the answer is quite meager. I don't know exactly which releases ship with rename set up to run prename through the alternatives system, and which ship with file-rename, though my 14.04 system had it. More importantly, I don't actually know what all the important differences are between prename and file-rename.

I'm pretty sure I've at some point experienced trying (on someone else's system, not sure what OS) to use that other rename (the rename.ul one) and had it do nothing at all I expected it to do.

That answer is a valiant effort... but it's not very specific, and it leaves something to be desired even in the material it does cover, because neither prename nor file-rename originated as a downstream Debian tool, and both of them are packaged by Debian developers. With prename, I believe you always get it with perl. With file-rename, I believe it would be necessary to install a CPAN module for it. But both are upstream utilities that are repackaged in .debs.

@EliahKagan I have read that answer but it didn't clear up my confusion... I see I have previously upvoted the question but not the answer

@EliahKagan maybe you could post a question about it :)

@Zanna Yeah, same here. Actually, years ago, I used rename in Red Hat Linux and expected it to be the utility that we run as rename.ul in Debian and Ubuntu. However, I never knew much more than very basic usage of it. (Also, this might've been before it split into RHEL and Fedora, i.e., <= RH9! -- to this day, RH6 is my favorite OS of all time. So it was a while ago.) More recently, I have used rename in some OSes and found it was rename.ul rather than prename or file-rename.

@Zanna I had hoped to post a self-answered question asking what the important differences are between prename and file-rename. But I didn't really find the answer. Obviously it is good to ask questions even when one doesn't oneself know the answer! But I fear that such a question would be seen, perhaps wrongly, as too broad, at least if asked without showing more specific discoveries than I've done enough research to show, thus far.

@Zanna They might, yes. Besides being sometimes useful itself (it performs the opposite action to that of xargs -0), the command printf '%s\0' simulates the effect of piping from find ... -print0. So while that command does not work, it does work if you set $/ first:

$ printf '%s\0' foo bar baz | rename -n 'BEGIN { $/ = "\0" } s/^/prefix /'
rename(foo, prefix foo)
rename(bar, prefix bar)
rename(baz, prefix baz)

That works because $/ is the special variable in Perl whose value is used as the input record separator. (Similarly, `$` is used as the output record separator.)

@EliahKagan ah thanks! I was trying to do it myself, but I couldn't get the syntax. It was telling me off for trying to set "$/ to zero as a form of slurp"

I do think the "primarily" in "primarily opinion-based" is often overlooked. This question might be closed as POB, too, on the grounds that which differences one considers important is a matter of opinion.

@Zanna Well slurping is when the input record separator is the empty string, so no splitting is performed... But what had you run, exactly, to get that warning?

Just like this: printf '%s\0' foo bar baz | rename -n '$/ = \0; s/^/prefix /'

no splitting was performed haha :)

Oh. I didn't even know about that.

Setting $/ to a reference to zero as a form of slurp is deprecated, treating as undef at (eval 4) line 1.

yeah, that one :)

I must really go to sleep :(

Also I should've said undef or the empty string. Really it's stylistically better to slurp by setting$/ to undef than to the empty string, since, conceptually, splitting on the empty string feels like it should mean splitting so that each character is taken to be a separate record. (And that is the behavior of Perl's built-in split function, when it matches an empty string as the splitter. But $/ = "" does work for slurping.)

I didn't know about the thing where people would set it to \0 (a reference to a 0 scalar) and that would slurp though.

@Zanna Good night!

@EliahKagan this is why I love rename's warnings :) You can learn so much just by doing suboptimal things

maybe you will feel like explaining something about perl -n and perl -p next time... you have time!

There's some weird magic going on with BEGIN, but the main thing I didn't say was that rename renames files when $_ is changed to a different value, and the default behavior of s/// (that is, the behavior when the r flag is not passed) is to actually modify the operand that appears to the left of =~.

thanks a lot for explaining $_ and introducing me to Perl awesomeness. I used to hear Linux people say "why would you want to use Perl when you can use Python?" but the more I hang around SE the more I think Perl is very cool. Especially if you don't like typing :)

@Zanna I look forward to it! You can also find them documented in the page shown by running perldoc perlrun, though that won't fully explain the special behavior you get with while (<>). Btw, that thing about Bash that I mentioned before... that was just one of two neat things I had learned. If you're interested, I may share the other one next time, too. :)

oh yes! Yesterday I thought "he said a couple of things, but he only mentioned one thing, so maybe there is more stuff coming...:)"

@Zanna The truth is that if I had to choose one, I would pick Python. I do think Perl is neat, though. And it will remain useful for a long time even if it doesn't bounce back in popularity compared to Python (which I think it probably won't), because there's a huge amount of code written in Perl, and some of that code is made useful by writing other Perl code that consumes it -- as is the case with the code argument passed to prename and file-rename.

(What I've been calling the "code" argument is really labeled "perlexpr" in the perldoc page, and in the manpage generated from it.)