Menu

#40 quotes

next
wont-fix
None
5
2023-03-04
2021-07-02
rno
No

dunno if its a featrequest or bug, yet seems to me there's some bug here:

if trying to pass a command with multiple files arg to another,
as with ssh or telnet or the like..., so a command using some quotes already

-

sh playerone -c 'gimp --no-splash {A}'
gimp starts only if the first filename is without spaces

-

if trying with
sh playerone -c 'gimp --no-splash {F}' + separate each entry + run in background
it does not recognise gimp being started somehow,
and show only one pic , then next closing gimp, another gimp is restarting showing the next pic...

-

I tried with double quotes, there's an error, also if filenames are without space
sh playerone -c "command --with --options {A}"
then the command fails with:

bash: -c: line 0: unexpected EOF while looking for matching `''
bash: -c: line 1: syntax error: unexpected end of file

looked in /tmp/worker/ seems the crafted script is ending with an escaped quote, only one.
also filenames are not quoted. also double quote are not there any longer.

-

expected: it would be useful if there were ways doing this,
or maybe a defintive statement in the doc or something it cannot be done
or maybe something else...

thought maybe a special quoted A variant {qA} ...
yet I dunno how this could be, and if flags really could be solutions...
am some lost here,

-

thanks again.

Discussion

  • Ralf Hoffmann

    Ralf Hoffmann - 2021-07-03

    This usage scenario is not supported. To avoid unexpected command execution, the command arguments are always protected within single quotes with limited additional shell functionality. No additional adjustments are made to make it work recursively (when the command calls another command expecting correct quoting for that command).
    You have to use a separate script for this use case.

    However, the invalid quoting you mentioned should not happen which looks like a bug. I cannot reproduce it right now, since using
    sh playerone -c "command --with --options {A}"
    results in a correct quoting for the outer command, even with files with spaces or quotes.
    Can you export the actual button or hotkey where you used that command? Also, does the file name contains additional unusual characters, like single or double quotes?

     
  • Ralf Hoffmann

    Ralf Hoffmann - 2021-07-03
    • status: open --> accepted
    • assigned_to: Ralf Hoffmann
     
  • rno

    rno - 2021-07-03

    hi,

    Ok, so it was an error in the button syntax, I saw it while preparing an export.
    in fact there was a quote error, something as
    sh playerone -c "command --with --options {A}'
    first quote double, second single

    the error is my side. I'm sorry about it, should have spent more time trying/testing earlier than sending this message : /

    This usage scenario is not supported.

    aknowledged

    To avoid unexpected command execution, the command arguments are always protected
    within single quotes with limited additional shell functionality.

    this is tough + complex to figure out, yet is aknowledged

    use a separate script for this use case.

    ok with me, so
    maybe saving them (the filenames) in a file with
    owncommand echo {F} >argsfile + separate each entry
    owncommand myscript argsfile

    ok then I will find ways along time.

    my side, report #40 can be closed.
    I' m sorry for the inconvenience/ time loss.

    thanks

     
  • Ralf Hoffmann

    Ralf Hoffmann - 2021-07-07
    • status: accepted --> wont-fix
     
  • rno

    rno - 2021-08-19

    hi

    so I did a button + an external script to quotes those filenames
    while doing the button I did a script,
    and found the script "settings" panel mention an "With quotes" option that isn't there.

    attached is an image of the setting panel showing the "With quotes" option mention.

    thanks

     

    Last edit: rno 2021-08-19
  • Ralf Hoffmann

    Ralf Hoffmann - 2021-08-22

    This text is actually a left-over from a fix almost 20 (!) years ago :-) Since then the arguments are always quoted and this option has been removed. There is actually a yet undocumented feature of flag replacement to disable quoting by prepending a dash at the flag name, but this still won't help for your case since you need correct recursive quoting which is not supported.

     

Log in to post a comment.