| Type | Issue | Status | submitted | Date | 24-Jul-2015 10:10 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Unspecified | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Interface for CALL function, specifically behavior w.r.t. the /SHELL refinement |
|---|---|
| Description |
Original discussion: https://github.com/metaeducation/ren-c/issues/19 -- transferred to CC to keep design discussions together in one place, for now. -- @rgchris reported that the following is interpreted as a path to a command, if you do not use the /SHELL refinement: >> call {curl http://rebol.info} ** Access error: external process failed: "No such file or directory" ** Where: call ** Near: call "curl http://rebol.info" That seems like it would be reasonable if it had been passed a FILE!, like: >> call %"curl http://rebol.info" Invoking the shell to parse and interpret a string parameter may make a reasonable default. But you sometimes want to pass the information uninterpreted, and directly as the ARGV[] received by the process. @earl responded in chat, mirrored to Ren/C issues: > One major hassle is the divergence in calling interfaces in process creation. > Windows: a single 'command-line' string. POSIX: argv. We'll have to come > up with a sensible cross-platform abstraction over that, eventually. I'm > currently leaning towards standardising something argv-like, that means > a i.e. a block with executable + arguments as @hostilefork describes as well. > On top of that, we add some polish to transmogrify that block into a workable > command-line string in the Windows world (that'll probably entail join + some > escaping). > > And if we go that route, implied /shell for a single string be, I think, a nice idea. > > I wouldn't completely drop /shell even with that default behaviour, because > there are more reasons than command-line splitting that might lead you to > want to wrap your command in a shell (set up of a full environment, for > example). And doing that, abstracted over platform-specifics with /shell is > still nice. @ShixinZeng said: > Yes, the main idea is to make it work across POSIX and windows, and > try to do as little work as possible in terms of disassembling and > reassembling arguments. > > For call {curl http://rebol.info} to work on POSIX systems, the interpreter > needs to first break it down to ["curl" "http://rebol.info"], and pass it to > exec*. It becomes complex, inefficient and inconvenient when the argument > contains spaces (quotes would be needed to make them a one argument). > e.g. call {cmd this an argument with spaces and quotes ^"}. This puts burden > on both the interpreter programmers (need to parse the argument) and script > programmers (need to remember how to group the arguments) for no good." > > When a block of arguments is passed in, it becomes very easy to handle > the spaces in the arguments: > > call [{this is an argument with spaces and quotes "}] > > The arguments are passed as-is to the underlying executable on POSIX > systems (easy and efficient). On windows, quotes needs to be added and > escaped when needed, and all of this can be handled by the interpreter > without much performance penalty. > > As for the /shell, it's very clear what it means when it's specified (running the > command through the shell), but what it means when it's not? I take it as the > opposite of "running through the shell": running the executable directly." |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 24-Jul-2015 22:46 |
|---|
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 24-Jul-2015 22:46 | abolka | Description | Modified | - |
| 24-Jul-2015 22:45 | abolka | Description | Modified | - |
| 24-Jul-2015 10:10 | Fork | Ticket | Added | - |