[Swift-devel] New built-in system, request for comments

[Yadu Nand Babuji]

I've committed the change for running the strings under bash, and wildcards
and pipes are working. I can now do bash one-liners neatly and I like that.

I tested with this :
string o[] = system("ls *.swift");
foreach t,i in o{
     tracef("o=%s\n",o[i]);
}

RunID: run021
Progress: Sat, 05 Apr 2014 22:49:15-0500
o=fail.swift
o=system.swift
o=shell.swift
o=t.swift
Final status:Sat, 05 Apr 2014 22:49:15-0500

while system("echo *.swift"); returns a single line which goes to tracef.
Like this :
RunID: run022
Progress: Sat, 05 Apr 2014 22:50:12-0500
o=fail.swift shell.swift system.swift t.swift
Final status:Sat, 05 Apr 2014 22:50:12-0500

-Yadu

On 04/05/2014 08:11 PM, Michael Wilde wrote:
>
> As I alluded to in a prior post (but didnt say clearly), Im in favor 
> of giving system a varying number of returns, something like:
>
> output = system("command");
> (output,error) = system("command");
> (output,error,rc) = system("command");
>
> Also letting output and error be either strings or string arrays.
>
> Not sure how much flexibility is best, though.
>
> Regarding treating function failures like app failures: I dont think 
> thats good in the case of functions.  Further, in the case of apps, we 
> have at least one user request to provide more flexible error handling 
> for app failures. So when the user requests an rc (from either), any 
> non-zero RC should be returned to the user and not cause the function 
> (app or built-in) to be considered failed. Null files can be returned 
> to preserve dataflow semantics.  This is not totally clear, and not 
> clearly "best", but should should consider it.
>
> Yadu, regarding the current implementation: I was about to send a note 
> to swift-user when I decided to test it first.  Im getting strange 
> errors when I try to do:
>
> string o[] = system("echo *.swift");
> tracef("o=%s\n",o[0]);
> # produces:
> o=*.swift
>
> string o[] = system("sh -c 'echo *.swift'");
> tracef("o=%s\n",o[0]);
>
> # produces:
> swift:system returned exitcode :1
> swift:system stderr:
>  *.swift': -c: line 0: unexpected EOF while looking for matching 
> `''*.swift': -c: line 1: syntax error: unexpected end of file
>
> Execution failed:
> java.lang.IndexOutOfBoundsException: Invalid index [0] for o
>     tracef @ system, line: 28
> Caused by: java.lang.IndexOutOfBoundsException: Invalid index [0] for o
>
> ---
>
> Yet:
> string o[] = system("sh -c 'date'");
> tracef("o=%s\n",o[0]);
> # produces:
> o=Sat Apr  5 20:08:29 CDT 2014
>
> So something strange is happening when I try to pass an argument with 
> shell wildcard chars to "sh -c".
>
> I think that system( ) by default should send its args to "sh -c" so 
> that wildcards and all related shell features are available.
>
> Lastly, note that in above, "echo" is just an experiment; what I 
> really want to do in this example is "/bin/ls -1 *.swift" for example.
>
> - Mike
>
>
> On 4/5/14, 7:01 PM, Yadu Nand Babuji wrote:
>> Ketan,
>>
>> Do we need that ? If you add stdout, stderr and say exitcode as 
>> returns, the user has no
>> choice but to define variables to hold those return values.
>>
>> Mihael mentioned in a separate thread that the behavior should be to 
>> fail early in case the
>> executed string returns a non-zero exitcode.
>>
>> -Yadu
>>
>> On 04/04/2014 10:58 PM, Ketan Maheshwari wrote:
>>> Is it possible to handle stdout and/or stderr of system("command") 
>>> separately? That way, it might be useful in other places as well.
>>>
>>>
>>> On Fri, Apr 4, 2014 at 12:08 PM, Yadu Nand <yadudoc1729 at gmail.com 
>>> <mailto:yadudoc1729 at gmail.com>> wrote:
>>>
>>>     Hi,
>>>
>>>     I have just added a new builtin "system" to trunk. It takes a
>>>     string,
>>>     which is executed in the shell
>>>     by java and the results are returned as an array. This is done
>>>     to make
>>>     mappings easier, for example,
>>>     you can map an entire folder "foo" using the following :
>>>
>>>     file folder[ ] < array_mapper; files = system ("find foo -type
>>>     f") >;
>>>
>>>     If the execution of the string provided fails, the logger would
>>>     report
>>>     the the exitcode and stderr to
>>>     the swift stdout.
>>>
>>>     Thanks,
>>>     Yadu Nand B
>>>     _______________________________________________
>>>     Swift-devel mailing list
>>>     Swift-devel at ci.uchicago.edu <mailto:Swift-devel at ci.uchicago.edu>
>>>     https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Swift-devel mailing list
>>> Swift-devel at ci.uchicago.edu
>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>>
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
> -- 
> Michael Wilde
> Mathematics and Computer Science          Computation Institute
> Argonne National Laboratory               The University of Chicago
>
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20140405/8534576a/attachment.html>