Resolving commandline parameters

[Bart]

Hi all,

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

Consider the following code:

Code: [Select]

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

My program expects input from the commandline in the form

Code: [Select]

scopy source dest

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

Code: [Select]

bart@simenon:~/LazarusProjecten/ConsoleProjecten/scopy> ./scopy *
1: backup
2: lib
3: scopy
4: scopy.ico
5: scopy.lpi
6: scopy.lpr
7: scopy.res
8: x
bart@simenon:~/LazarusProjecten/ConsoleProjecten/scopy>

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

Code: [Select]

scopy source dest excludefilter


Code: [Select]

bart@simenon:~/LazarusProjecten/ConsoleProjecten/scopy> ./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

[bobo]

How about using separator parameters?

Something like "./scopy --src *  --dest y --excl *.bak"
and processing the paramlist you can always know when the different parts start.

[Bart]

I thought of that, but I find it really counter-intuitive.

Neighter copy (on Windows) or cp (Linux) use this for specifying source and destination.

It makes sense to use a prefix (--) for the exclusionmask though.

Bart

[TurboRascal]

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?

You can get the parameters by quoting and escaping wildcards, but other than that there is no way to get the typed parameters after the shell finished hashing it. Examples,

Quoting:

Code: [Select]

./scopy '* *.bak'
./scopy '*' '*.bak'
./scopy "* *.bak"
./scopy "*" "*.bak"

Escaping:

Code: [Select]

./scopy \* \*.bak

I hope you get the idea. That way you actually get the wildcard characters.

Perhaps the easier way would be to define your own wildcard. For example, in SQL queries the wildcard character similar to '*' is '%'.

[Bart]

You can get the parameters by quoting and escaping wildcards

I know about quoting/escaping.

What I really meant was, I'ld like to process the wildcards myself, without making the end-user using un-common syntax.
The end-user is going to expect typing *, not '*'.

I'll just go with the flow and accept that wildcard expansion is there and deal wiht it.

As marcov explained to me, the last parameter on the (expanded) commandline in this case will be "dest", this is in fact how "cp" in linux works.

If you are in a directory that contains the files "1", "2", "3" and a directory "x" (all without quotes), then the following command wil in fact copy all files to the "x" directory:

Code: [Select]

bart@simenon:~/test/>cp *

This is because "x" wil be the last parameter in the expanded wildcard list.

I guess Linux users are supposed to be smart enough to realize this, and so not to forget to actually type the "dest" parameter.

Bart