having --help and --version exit without error is goodness. IIUC the problem here is that the info answered by --help (usage()) is also printed on error. So usage should still be printed when the vm is invoked with invalid arguments and the vm should exit with an error code but should not answer an error code if usage is present noted in response to --help.
> On May 7, 2017, at 10:21 AM, Ben Coman <
[hidden email]> wrote:
>
>
>> On Mon, May 8, 2017 at 12:21 AM, Eliot Miranda <
[hidden email]> wrote:
>>
>>
>> IIABDFI
>> Esteban rewrote the code that use -- for Pharo, preserving - for Squeak. What's the problem??
>
> No problem for me. Just trying to help progress Subbu's PR.
> This removes the double-dash "#ifdef PharoVM".
> My question was a consequence of going forward with that,
> but now I guess that part should be reverted.
>
>
> Another part of the PR seems to deal with regression of Pharo --help exit code
>
> Pharo5$ ./pharo --help > /dev/null ; echo $?
> 0
> Pharo6-stable-threaded-20170503$ ./pharo --help > /dev/null ; echo $?
> 1
> Squeak5.1-16549-32bit-20160817$ ./squeak.sh -help > /dev/null ; echo $?
> 1
>
> but the PR would also change "squeak --help" exit code to 0,
> So perhaps that is unacceptable and either:
> * the exitcode needs adding to the #ifdef,
> * Pharo adopts the Squeak convention,
> (although intuitively --help completes successfully implying a 0 exit code)
>
> Here is a direct link to the diff...
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/136/files#diff-9e9b14913ecc2dd4edb6c03082408fd1L1423>
> cheers -ben
>
>>
>>
>> _,,,^..^,,,_ (phone)
>>
>> On May 7, 2017, at 8:50 AM, Ben Coman <
[hidden email]> wrote:
>>
>> @bencoman requested changes on this pull request.
>>
>> Can we have some discussion on [vm-dev] about the flexibility of Squeakers to use double-hyphen options as default?
>>
>> ________________________________
>>
>> In platforms/unix/vm/sqUnixMain.c:
>>
>>> @@ -1467,7 +1464,8 @@ static int vm_parseArgument(int argc, char **argv)
>>
>> /* vm arguments */
>>
>> - if (!strcmp(argv[0], VMOPTION("help"))) { usage(); return 1; }
>> + if (!strcmp(argv[0], VMOPTION("help"))) { usage(0); /*NOTREACHED*/}
>>
>> Would it be better to shift the exit() out of usage(), so that real code affection execution flow is used here rather than a comment. i.e. here... { usage(); exit(0) } ??
>>
>> ________________________________
>>
>> In platforms/unix/vm/sqUnixMain.c:
>>
>>> @@ -1721,7 +1719,7 @@ static void usage(void)
>> printf("\nAvailable drivers:\n");
>> for (m= modules; m->next; m= m->next)
>> printf(" %s\n", m->name);
>> - exit(1);
>> + exit(exitValue);
>>
>> Refactor the exit() out to the caller ??
>>
>> ________________________________
>>
>> In platforms/unix/vm/sqUnixMain.c:
>>
>>> @@ -1819,7 +1817,8 @@ static void parseArguments(int argc, char **argv)
>> if (n == 0) /* option not recognised */
>> {
>> fprintf(stderr, "unknown option: %s\n", argv[0]);
>> - usage();
>> + usage(1);
>> + /*NOTREACHED*/
>>
>> Same as above, refactor exit out of usage() ? i.e. here...
>> usage();
>> exit(1)
>>
>> ________________________________
>>
>> In platforms/unix/vm/sqUnixMain.c:
>>
>>> {
>> struct SqModule *m= 0;
>> printf("Usage: %s [<option>...] [<imageName> [<argument>...]]\n", argVec[0]);
>> printf(" %s [<option>...] -- [<argument>...]\n", argVec[0]);
>> + printf("options begin with single -, but -- prefix is silently accepted\n");
>>
>> The problem is that single-hyphen default is then what is advised by --help. Why isn't it preferable to conform to Unix conventions [1] "The GNU double-hyphen option leader was chosen so that traditional single-letter options and GNU-style keyword options could be unambiguously mixed on the same command line. "
>> [1]
http://www.catb.org/~esr/writings/taoup/html/ch10s05.html>>
>> The single-hyphen could be silently accepted for backward compatibility. Maybe better would be a deprecated message, but perhaps that could adversely affect existing scripts(?).
>>
>> How do Squeakers feel about that?
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub, or mute the thread.
>>
>>
Locked
