I’m writing a small package involving some user interaction in the style of unix command line interactive utilities. The package SimpleArgParse.jl with some adaptations would do the parsing, however it needs to be provided with arguments as a vector of strings (ARGS). The command line arguments are presumably parsed by OS, but for the interactive use I must do it on my own. For the simple cases like -a AA -b BB
the split(s) function would perfectly do the job. Now, I can have enquoted text like -f "C:\user folder\"
to be made into ["-f", raw"C:\user folder\"]
and all kinds of special cases that can arise.
I hope (and almost sure) there exist a ready to use solution for that
For interactive use, why not just have the user pass an array of strings via Julia code? Julia is already a perfectly good language for interactivity, so why would you emulate a more primitive language like sh on top of this?
In an act of escape gymnastics worthy of Houdini, you can try the following:
julia> s = "-a AA -b BB"
"-a AA -b BB"
julia> readlines(`sh -c "for arg in $s; do printf \"%s\\n\" \"\$arg\" ; done" 0`)
4-element Vector{String}:
"-a"
"AA"
"-b"
"BB"
julia> s = "-f \"C:\\\\user folder\\\\\""
"-f \"C:\\\\user folder\\\\\""
julia> v = readlines(`sh -c "for arg in $s; do printf \"%s\\n\" \"\$arg\" ; done" 0`)
2-element Vector{String}:
"-f"
"C:\\user folder\\"
julia> println(v[2])
C:\user folder\
julia> println(s)
-f "C:\\user folder\\"
The goal is to use the actual command shell to parse the arguments. And it works. The DOS style paths with the backslash directory separator posed an additional challange. But this challange may be present even in ideal cases.
Also, historical note, Houdini actually died from his escape artistry.
But shelling out sucks because of all the tricksy escaping, and it’s still not clear to me why you want to emulate this behavior in Julia rather than just using Julia as your interface.
@stevengj, thank you! Base.shell_split should do the job.
Actually I just want to provide a simple way (simple to implement and simple to use) for the user to supply some minimal information. A file path is actually not an intended data: NativeFileDialog.jl would rather be used for that. I’ve just taken a Windows file path as an illustration of a tricky case - actually a too tricky one. Yes, in principle I’m aware of all these “escapism” problems.