Bareword found where operator expected

[rpdelaney]

$ brew info rename
rename: stable 1.600 (bottled), HEAD
Perl-powered file rename script with many helpful built-ins
http://plasmasturm.org/code/rename
Conflicts with:
  util-linux (because both install `rename` binaries)
/usr/local/Cellar/rename/1.600_1 (4 files, 41.9KB) *
  Poured from bottle on 2018-09-10 at 16:13:29
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/rename.rb
==> Options
--HEAD
	Install HEAD version
==> Analytics
$ rename -- '_%28Civ5%29' '' *
install: 3,789 (30 days), 13,064 (90 days), 47,263 (365 days)
install_on_request: 3,472 (30 days), 11,602 (90 days), 43,035 (365 days)
build_error: 0 (30 days)
Bareword found where operator expected at (eval 2) line 1, near "28Civ5"
	(Missing operator before Civ5?)
Bareword "_" not allowed while "strict subs" in use at (eval 2) line 1.
syntax error at (eval 2) line 1, near "28Civ5"

[ap]

Well that’s a tricky one.

What’s going on is that -- means not to parse anything that follows it as switches. And if you don’t supply any renaming expression, then after all command line parsing has been done, the first non-switch argument is checked for whether it’s the name of an existing file, and if it’s not (as is the case here), it’s assumed to be a Perl expression you want to use to modify the filenames. So it tries to compile _%28Civ5%29 as Perl code, and that’s why you get that particular error.

It’s hard to know what to do in this case.

What were you actually trying to do? I am guessing you wanted to type -s to remove the string _%28Civ5%29 from a bunch of files, but you accidentally typed -- instead – is that correct?

If so, I cannot off-hand think of a way to usefully detect your mistake for you. The only sure thing that comes to mind is that it could catch the empty-string argument and complain that a file with an empty name cannot possibly exist. But that only happens to work in your particular example of passing an empty string as the substitution, not in any other case. In any other case (such as renaming to another non-empty string, or using -d rather than -s with an empty second argument) it wouldn’t help.

My first instinct was to check if -- had been passed, and if so, make sure to never use an argument from after the -- as a code expression. That would be how I would define the semantics if I thought about it explicitly: everything that follows -- is taken to be a filename. And if this was how the code worked, then you would simply have gotten an error that you didn’t specify how to rename the files. I had not reasoned out that this is not how the code actually works – that it will happily take an argument from after a -- as a Perl code expression.

But now that I realise that this is how the code I’ve written actually works… I must wonder if anyone is actually relying on that, on purpose. If so, how hard will it be for them to realise that this has changed and their shell scripts got broken – and how hard will it be for them to fix? And of course the flipside is, how many people’s shell scripts would I fix by making this change? Hard to say. But it’s not a choice I want to make just like that, unexamined, purely in pursuit of an abstract notion of correctness.

I’m afraid I have nothing more to offer in the immediate moment than “don’t do that then”.

[rpdelaney]

I got into the habit of using -- because otherwise hyphens in the pattern or the target files confuse rename. It's almost muscle memory at this point.

$ ls
--this-is-a-file        -file                   file                    file-
$ rename '--' '' *
$ ls
--this-is-a-file        --this-is-a-file-file   --this-is-a-filefile    --this-is-a-filefile-
$ 

I don't know what's going on with that, but it's not the outcome I wanted.

On the other hand, this gets me to my endgame:

$ ls
--this-is-a-file        -file                   file                    file-
$ rename -- '--' '' *
$ ls
-file           file            file-           this-is-a-file
$ 

Also, there's this:

$ ls
--this-is-a-file        -file                   file                    file-
$ rename -- 'file' 'thing' *
$ ls
--this-is-a-thing       -thing                  thing                   thing-
$ rename 'thing' 'file' *
rename: unrecognized option `--this-is-a-thing'
Try 'rename --help' for more information.
$ 

Lots of common shell utilities are vulnerable to that and I don't think there's a better solution than parsing --, which rename has done as I expected up to this point. That part is fine, as far as I'm concerned.

the first non-switch argument is checked for whether it’s the name of an existing file, and if it’s not (as is the case here)

I may misunderstand you, but I think this means this should fail too, but it doesn't:

--this-is-a-file        -file                   file-
$ rename -- 'file' 'thing' *                                                                                                                                                                        
$ ls
--this-is-a-thing       -thing                  thing-
$

It’s hard to know what to do in this case.

I know very, very little perl and even less about how rename works. But at the very least, a less cryptic error would be an improvement. If you decide an improvement is worth the effort to you.

And if this was how the code worked, then you would simply have gotten an error that you didn’t specify how to rename the files.

Well, I did. I thought. I mean, I've used the rename -- 'thing_to_remove' '' [files] pattern many times, but this is the first time I got this problem. Maybe that is actually an antipattern somehow, but ...

$ ls
--this-is-a-thing       -thing                  another-thing
$ rename -- 'thing' '' *
$ ls
-               --this-is-a-    another-
$ 

That seems intuitive to me, from where I'm sitting.

But it’s not a choice I want to make just like that, unexamined, purely in pursuit of an abstract notion of correctness.

You'll get no argument from me on that point, to be sure.

I’m afraid I have nothing more to offer in the immediate moment than “don’t do that then”.

Okay, well. If that's the final answer, can you suggest a better pattern?

[ap]

OK, wait, this is confusing two different programs.

If you do rename '--' '' * with my rename, then nothing will happen. (That’s because first the command line is scanned for switches, which there aren’t any; then the -- gets discarded; then the first argument is taken as a Perl expression that performs the renaming. And the first argument is empty. So nothing is done.)

The result you are seeing happen if you are using the util-linux rename program, which is a completely different beast, entirely unrelated to the program in this repository. That program expects its first two non-switch arguments to be a substring to match and a substitution to replace it with. What happens is that the shell expands your * to a list of filenames before running rename, so its first argument is your empty string, its second argument is the first filename from the list of filenames, and the rest of the list of files to rename is taken as the files to rename. The empty string can be found at the front of any filename, so it amounts to prepending the substitution to each filename. So the name of the first file named by * gets prepended to every other file. There is nothing that rename can do in this case, because it has no idea whether or where you used * – the shell expands that before it runs the rename program, so rename itself never sees it.

But, again, that has nothing to do with my rename program…

However, “Bareword not allowed” most certainly is an error that results from my `rename.

So the answer to “what were you actually trying to do when you got this error” appears to be “I was trying to call the util-linux rename but yours got run instead”.

In which case the “pattern” I would suggest is “figure out what’s in your $PATH and why and make sure the right program is installed”. 😊

[rpdelaney]

TIL there are two of these. I guess I should be on the lookout for a collision when a thing is called something like rename. Sorry about that.

[ap]

No worries. 😊