ls *.pdf complains: ls: invalid option -- '

I'm used to using 'ls' as I would in Linux Mint, e.g. 'ls *.pdf', but in this Debian variant 'ls .pdf' complains. I find myself using a length 'find -maxdepth 1 -type f -name ".pdf" -print' instead.

Reading this: ls working strangely did not help too much. I do have bash_completions package and I have no weird aliases for 'ls' in my '~/.bashrc' file - I never edit the '/etc/profile' or the global one, wherever it is.

Just guessing, I did apply the solution in the linked question but it didn't work. I don't fully understand 'complete' - I guess it is part of 'readline' - so maybe a short explanation would help too (It has no 'man' page).

This works though: 'complete -p ls *.pdf', which 'complete --help' says,

 -p        print existing completion specifications in a reusable format

and so I wonder if I should permanently apply this 'rule'? using the '-D' flag...?

EDIT

Just noticed this problem too:

for f in *.pdf; do mv "$f" "BOOK - $F"; done

mv: invalid option -- 'R'

EDIT 2

I tried the two commands above and they work fine - on my OS's partition. The problems are when I move to a different partition, with the working Linux Mint on it and the pdf files I want to modify, that these commands fail. Both partitions are ext4, both have the same username, hostname, UID/GID, permissions, etc.

nate

Posted 2018-03-04T19:06:45.087

Reputation: 149

Answers

It seems like you have filenames with leading dash -, so use :

for f in *.pdf; do mv -- "$f" "BOOK - $F"; done

From man bash :

A -- signals the end of options and disables further option processing. Any arguments after the -- are treated as file‐ names and arguments. An argument of - is equivalent to --.

Gilles Quenot

Posted 2018-03-04T19:06:45.087

Reputation: 3 111

Is that some sort of Bash magic? I don't see it in the man page for mv... – nate – 2018-03-04T19:19:41.003

1It's not specific for mv but for shell, it means end of options – Gilles Quenot – 2018-03-04T19:24:04.730

@nate, see this for more info. TL;DR: this is a convention put forward by GNU libc (the standard C library typically used on Linux-based systems) and the core/file utilities written with its help. The convention sort of stuck (for good).

– kostix – 2018-03-05T08:07:41.683

I'd also explain why the observed behaviour happens. Unix shells (contrary to those of Windows) expand "wildcards" by themselves; that is, when you run some_command *.pdf in your shell, the shell sees that *.pdf and tries to match the set of files in its current directory; if that happens, the some_command will be passed several distinct arguments—each being the name of a single file that matched. If the matching fails (no files found) the argument will be passed as is—*.pdf. – kostix – 2018-03-05T08:11:56.510

…As a corollary, you could even have files named --, -a and -b, and call some_command -* with some interesting (and unpredictable, from run to run) results ;-) What I'm leading to, is the for production code you'll almost always want find $dir -type f -name '*.pdf' -print0 | xargs -0 -n 1 some_command – kostix – 2018-03-05T08:13:43.257

If you have filenames that start with - (minus or hyphen), many programs interpret them as options.

You can prepend ./ to the path to avoid it:

ls ./*.pdf

Many programs also allow inserting -- before filename arguments to signal end of options:

ls -- *.pdf

The recommended approach for users is of course to rename the files.

Ivan

Posted 2018-03-04T19:06:45.087

Reputation: 178

Oh, I see. So just a simple file name starting with a dash caused these errors. I did find one and renamed it and now it works. – nate – 2018-03-04T20:03:55.310

ls *.pdf complains: ls: invalid option -- '_'

Answers