/feed with non-avoidable double quotes?

[highend]

An external application exports paths that do not contain spaces without any embracing quotes. Neither single nor double.

Code: Select all

/feed="::text '%external_path%';"

So if %external_path% is: R:\a, the resolved /feed is:

Code: Select all

/feed="::text 'R:\a';"

works fine in that case...

But when paths contain space(s), they are embraced with double quotes
E.g.: "R:\a b c" will lead to:

Code: Select all

/feed="::text '"R:\a b c"';"

which would produce only the output of a single quote because /feed will think that the script ends on the second double quote (in this case the one before the R)...

Any ideas how to solve this (I have no control over the external application and it's behavior)?

[FluxTorpedoe]

Hello highend,

This is a wild and blind guess (I’ve no such external feeder to test), but would it work if you replaced the double quotes upstream?

Code: Select all

/feed="::text replace('%external_path%', chr(34));"

[highend]

Hi Flux,

no, this would output just:

Code: Select all

replace('

because the first double quote from the resolved %external_path% is still the "barrier"

[jupe]

What about adapting something like this:

Code: Select all

XYplorer.exe /user="%external_path%" /feed="::if get('CmdLineUser', 1) == '' {echo 'quoted';} else {echo 'no quotes';}"

e.g.
XYplorer.exe /user=%external_path% /feed="::text get('CmdLineUser');"

Without knowing your exact usage scenario or personally testing it, I guess it would only work with single files though, or maybe your external app does separate them by |, I wouldn't know.

[highend]

@jupe:
It's always only a single path / file

The first example always returns "quoted" and the second one always displays... nothing...
Even if it is an unquoted path with no spaces in it.

Weird!

I guess it's better to solve the issue upstream instead of messing around with it in XY...

[jupe]

That is extremely weird, that means that the %external_path% variable is being set as blank now (otherwise the variable name would be shown), I don't see how it could of worked in your first post example then.

Maybe bizarrely the external app needs it near the end of the command line

Code: Select all

XYplorer.exe /feed="::text get('CmdLineUser');" /user=%external_path%

Anyway yes you are right, upstream would be a better solution.

[jupe]

Just tested it, and realized what the problem was, it would only work when combined with the /new switch too, ie. /user is only resolved once on loading XY, or it could be parsed from <get copieddata 3> subsequently.

edit: A theoretically working, but messy solution:

Code: Select all

XYplorer.exe /user=%external_path% /feed="::if $P_hwnd == <hwnd> { $result = replace(substr(trim(gettoken(<get copieddata 3>, 2, '/')),5), chr(34));} else {perm $P_hwnd = <hwnd>; $result = <get cmdlineuser>;} text $result;"

edit2: actually, this is maybe a slightly cleaner way, but still not great:

Code: Select all

XYplorer.exe /feed="::if $P_hwnd == <hwnd> { $result = replace(gettoken(<get copieddata 3>, -1, '='), chr(34));} else {perm $P_hwnd = <hwnd>; $result = <get cmdlineuser>;} text $result;" /user=%external_path%

[highend]

Thanks for the effort jupe, but it doesn't work here as well
Output:

Code: Select all

::if $P_hwnd = <hwnd> { $result = replace(substr(trim(gettoken(<get copieddata 3>, 2, '

No time to debug it atm, I'll ask the upstream source for a better way to export that variable >)

[admin]

I invented piping as an alternative to quoting. Try this in the next beta:

Code: Select all

/feed=|::text '%external_path%';|

[highend]

Thanks Don, this solves it (ofc the script needs to trim the double quotes from it)