Hi all,

I ran into a problem with resolving commandline parameters, due to wildcard expansion by bash.

Consider the following code:

  for i := 1 to paramcount do writeln(i,': ',paramstr(i));

My program expects input from the commandline in the form

scopy source dest

when you now specify wildcards on the commandline, they will be expanded by bash, so the output will be like this:

./scopy *

1: backup
2: lib
3: scopy
4: scopy.ico
5: scopy.lpi
6: scopy.lpr
7: scopy.res
8: x

However from inside my program I cannot distinguish between the followin 2 scenarios:
1: x is the last item in the list expanded by bash or 2: the commandline actually was "scopy * x"

Scenario 1 is a syntax error, and it should not be treated as if it were scenario 2.

Things get even more confusing when i use a syntax like

scopy source dest excludefilter

./scopy * y *.bak

1: 123
2: 1233
3: 12333
4: 123.bak
5: 123.tmp
6: 456.bak
7: backup
8: lib
9: scopy
10: scopy.ico
11: scopy.lpi
12: scopy.lpr
13: scopy.res
14: x
15: y
16: 123.bak
17: 456.bak

Obviously this is a common scenario on Linux, so how to treat it?

I would prefer to expand the wildcards by myself, but it seems I have no access to what the user actually typed on the commandline?

Bart

Al 10/04/11 01:34, En/na Bart ha escrit:

Obviously this is a common scenario on Linux, so how to treat it?

You don't, accept the fact and don't try to oppose resistance ;-)

I would prefer to expand the wildcards by myself, but it seems I have no access to what the user actually typed on the commandline?

The only way is to single quote parameters:

./scopy '*' y '*.bak'

(see, e.g., the manual page for find).

Bye

[snip]

[snip]

Obviously this is a common scenario on Linux, so how to treat it?

Just live with it... Normal "cp" works like that as well.

E.g.:

echo "Hello World 1" > test1 echo "Hello World 2" > test2 cp test* cat test*

Hello World 1
Hello World 2

Regards,
Sven

[snip]

You cannot access that. If you want the wildcards, the user must escape them himself.

Michael.

In our previous episode, Luca Olivetti said:

Or change the syntax in a way that the last command is not a wildcard.

mv/cp work that way, they assume the last argument is a destination, and all others are generated by wildcards.

On Sun, 10 Apr 2011 11:50:56 +0200 (CEST), Michael Van Canneyt wrote about Re: [fpc-pascal] Parsing commandline parameters with wildcards on Linux:

On Sun, 10 Apr 2011, Bart wrote:

[snip]

A program can open /proc/self/cmdline as a text file, and retrieve its command line to re-parse it for itself.

Quick test: this does also contain the already extended command line.

Regards,
Sven

And the reason is that wildcard expansion is performed by the shell. The shell then execute the program using the expanded command line. /proc/self/cmdline is a virtual file exposed by the kernel containing the command line parameters it received. The kernel obviously has no clue about what the shell did or did not do.

Jonas

I thought of that too.
This then seems the way to go.
Yet another hurdle for making the program cross-platform.

Thanks all for the input.

Bart