Paramstr has unpredictable behaviour with double-quote characters

[KodeZwerg]

Sorry that I do ask since it is somehow unclear to me, for what purpose do you need quotes as part of interface to your application?

[ad1mt]

Code: Text  [Select][+][-]

1. program_that_requires_a_password  -p 'pas"word'

That's a command line typed into a shell, where the password has double-quote character in the middle.
I don't want to have to tell the user of my program_that_requires_a_password that they cannot have a double-quote character in their password.
This is just an illustration; I can think of many examples where I might want a program that has double-quote characters in a parameter.
EDIT - password on the command line is a bad example!  See a better example below!

[CCRDude]

Every OS has - different - standards on how to escape these.

If you provide a command line tool, you might assume that users know how to escape control characters on their specific command line - providing a generic behaviour across all platforms that might contradict a local behaviour might confuse them.

[CCRDude]

Another thought: providing passwords as parameters always has the danger that the password will be logged (.bashrc, process list shows parameters, &c).
If it's console, ask for it. And it should be automated, the user can write the password to the input pipe.

[avra]

Why don't you simply do it something like this:

Code: Pascal  [Select][+][-]

1. program get_cmdline_1;
2. uses
3.   Classes, SysUtils;
4. var
5.   Words: TStringList;
6.   i: integer;
7. begin
8.   WriteLn('cmdline = [', cmdline, ']');
9.   Words := TStringList.Create;
10.   try
11.     Words.DelimitedText := StringReplace(cmdline, '"', '\Quote/', [rfReplaceAll]);
12.     for i := 0 to Words.Count - 1 do
13.       WriteLn('Param ', i, ': ', Words[i]);
14.   finally
15.     Words.Free;
16.   end;
17. end.

for which the output on Win11x64 CMD is:

C:\Prg\Lazarus\FixesAll\projects>get_cmdline_1.exe a "b" 'c' '"d"' "'e'" 'f g' "h i" '"' "'"
cmdline = [get_cmdline_1.exe  a "b" 'c' '"d"' "'e'" 'f g' "h i" '"' "'"]
Param 0: get_cmdline_1.exe
Param 1: a
Param 2: \Quote/b\Quote/
Param 3: 'c'
Param 4: '\Quote/d\Quote/'
Param 5: \Quote/'e'\Quote/
Param 6: 'f
Param 7: g'
Param 8: \Quote/h
Param 9: i\Quote/
Param 10: '\Quote/'
Param 11: \Quote/'\Quote/

You would have to deal with blanks inside of quotes to get what you want, but that should not be too difficult...

[ad1mt]

The point I'm trying to make here, is that it's impossible to make your parameter processing code work on any platform.
Unless your code looks like this:

Code: Text  [Select][+][-]

1. {$ifdef windows) do windows stuff {$endif}
2. {$ifdef Lunix} do lunix stuff {$endif}

But even then, I think it might be impossible to figure out what the user actually typed from a generic piece of code.

[KodeZwerg]

I would prefer to say that the way you managing passwords is wierd, unusal and insecure.
Passwords should be entered and managed inside apps not outside or read for example from an encrypted file to have at least a little security.
Your current way is so easy to spoof out that every computer admin would forbid its usage, at least on windows.
If you still insist using an argument for password, i'd suggest that you handle in your app the entering of it, based on that produce a hash, based on that produce a base64, reply that base64 to your user to write it down, now special characters are no problem anymore, user just need to apply that one base64 block.
Still such method suck from point of security.

[Thaddy]

I would prefer to say that the way you managing passwords is wierd, unusal and insecure.
<snip>
Still such method suck from point of security.

I totally agree, except it is not unusual. There are more silly ones than proper ones.
1) Passwords should be stored as a one-way hash.
2) Hashing a password should just take one (1) byte of memory while hashing.... You should simply handle a password byte by byte.
3) AND IT SHOULD BE A ONE-WAY HASH, not the password.

[ad1mt]

I would prefer to say that the way you managing passwords is wierd, unusal and insecure.
Passwords should be entered and managed inside apps.

OK... visible password on the command was a bad example.
An better example might be... I implement a new language interpreter, and I want the user to be able to enter a single line of code, and have that code executed, like this:

Code: Bash  [Select][+][-]

1. qerl -e 'print "ASCII Table\n"; $v=32; while ($v < 127) {print("$v=",chr($v)," ");$v++;}'

Is that better?

[Thaddy]

No! and we gave you very good answers why...

[ad1mt]

Why don't you simply do it something like this:

Code: Pascal  [Select][+][-]

1. program get_cmdline_1;
2. etc

You would have to deal with blanks inside of quotes to get what you want, but that should not be too difficult...

Yes, I will likely have to re-invent getopts and/or paramstr.
I would have much prefered to use getopts or paramstr, but was disapointed that neither of them work consisently across all shells/platforms.

[KodeZwerg]

I would prefer to say that the way you managing passwords is wierd, unusal and insecure.
Passwords should be entered and managed inside apps.

OK... visible password on the command was a bad example.
An better example might be... I implement a new language interpreter, and I want the user to be able to enter a single line of code, and have that code executed, like this:

Code: Bash  [Select][+][-]

1. qerl -e 'print "ASCII Table\n"; $v=32; while ($v < 127) {print("$v=",chr($v)," ");$v++;}'

Is that better?

No! and we gave you very good answers why...

You are full correct Thaddy!

@ad1mt
Please re-read what I have told about restricted keywords, in that case misusing pipe-in symbol "<".
So if you want to be a script guy, write a script that your app can interprete or get that stuff within your app and learn what on a CL is legal and what not, do that for each platform you want to support and stop repeating same errors.
Good luck on reinventing the wheel!