I think having a specific flag to use that disables all the input and output magic is the correct way to go. --rawCIN does this for input. Is there a --rawCOUT?
Regards, Elias On 7 February 2017 at 19:54, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi Elias, > > that would tell you if your stdin is a terminal. But as we have seen below > this is always > the case with zsh even if apl is called from a script. zsh behaves exactly > as if the first script line > (but without the leading #!**) was entered manually but then does not do > the same with subsequent > lines but instead keeps reading from stdin of the calling process. > > /// Jürgen > > > On 02/07/2017 12:24 PM, Elias Mårtenson wrote: > >> Shouldn't you be able to simply call isatty(0) to determine this? >> >> Regards, >> Elias >> >> On 7 February 2017 at 19:21, Juergen Sauermann < >> juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>> >> wrote: >> >> Hi Xiao-Yong, >> >> yes, and GNU APL is doing a similar thing. However, the problem >> seems to be that the >> shell is not piping the rest of the script into the stdin of the >> called interpreter, but instead >> cloning its own stdin. >> >> And according to the argv printout below, GNU APL has no chance to >> tell if it was called directly >> by the shell or via an apl script. And due to that, it behaves as >> if it was called directly. >> >> /// Jürgen >> >> >> On 02/06/2017 10:03 PM, Xiao-Yong Jin wrote: >> >>> In terms of how interpreters should do with multiple arguments in >>> the #! line, perl's behavior is useful. >>> The following is from 'perldoc perlrun' >>> >>> The "#!" line is always examined for switches as the line is >>> being parsed. >>> Thus, if you're on a machine that allows only one argument with >>> the "#!" >>> line, or worse, doesn't even recognize the "#!" line, you still >>> can get >>> consistent switch behaviour regardless of how Perl was invoked, >>> even if >>> -x was used to find the beginning of the program. >>> >>> You may also want to read the rest of the document. >>> >>> On Feb 6, 2017, at 2:06 PM, Juergen Sauermann<juergen.sauermann@t- >>>> online.de> >>>> <mailto:juergen.sauerm...@t-online.de> wrote: >>>> >>>> Hi Xiao-Yong, >>>> >>>> thanks a lot for this explanation! >>>> >>>> /// Jürgen >>>> >>>> >>>> On 02/06/2017 08:25 PM, Xiao-Yong Jin wrote: >>>> >>>>> I would guess he is using zsh instead of bash. >>>>> zsh allows interpreter after #! without an absolute path, >>>>> irrelevant of the OS kernel. >>>>> >>>>> Try running the following script under zsh: >>>>> >>>>> ---- SCRIPT BEGIN ---- >>>>> #!bash >>>>> echo 'this will fail' >>>>> ---- SCRIPT END ---- >>>>> >>>>> You will get >>>>> >>>>> ---- OUTPUT BEGIN ---- >>>>> bash: echo 'this will fail' >>>>> : No such file or directory >>>>> ---- OUTPUT END ---- >>>>> >>>>> Zsh under both Linux and OSX should give this error, because zsh >>>>> is making the syscall with its own interpretation of the shebang line. >>>>> >>>>> On the other hand, with the absolute path, you get the standard >>>>> OSX kernel handling the syscall. >>>>> Google gives a detailed list of behaviors on a webpage >>>>> http://www.in-ulm.de/~mascheck/various/shebang/ >>>>> <http://www.in-ulm.de/%7Emascheck/various/shebang/> >>>>> Your code supporting argv[1] with a concatenated string like '-l >>>>> 37 --script --' may not be the best practice, IMHO, and should be avoided. >>>>> >>>>> Putting more than 1 argument on the shebang line is calling for >>>>> troubles if you want cross OS/kernel support. >>>>> >>>>> On Feb 6, 2017, at 12:43 PM, Juergen Sauermann< >>>>>> juergen.sauerm...@t-online.de> >>>>>> <mailto:juergen.sauerm...@t-online.de> wrote: >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> very odd indeed. It very much looks like OSX is starting apl but >>>>>> then not piping >>>>>> the subsequent lines of the script into APL. As if they are >>>>>> opening the script with >>>>>> popen() instead of execve(). Its probably more a problem of the >>>>>> shell than of >>>>>> the entire OS. >>>>>> >>>>>> I would also believe that after starting the script you are in >>>>>> immediate execution >>>>>> mode in GNU APL but with input echo off (apl was started with >>>>>> --script). >>>>>> >>>>>> I suppose if you replace '--' by '-f' in your first script line >>>>>> (without mentioning the >>>>>> script name as I proposed earlier), then it should work. >>>>>> >>>>>> BTW a non-absolute path does not work in GNU/APL, which shows how >>>>>> different the >>>>>> platforms are in this area. >>>>>> >>>>>> /// Jürgen >>>>>> >>>>>> >>>>>> On 02/06/2017 06:45 PM, Alexey Veretennikov wrote: >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> Finally I've down to something. >>>>>>> So the difference is whether I specify full path to apl in a file >>>>>>> header. >>>>>>> Consider: >>>>>>> head -1 aaa.apl >>>>>>> #!apl -l 37 --script -- >>>>>>> >>>>>>> sizeof(Svar_record) is 328 >>>>>>> sizeof(Svar_partner) is 28 >>>>>>> increasing rlimit RLIMIT_NPROC from 709 to infinity >>>>>>> >>>>>>> initializing paths from argv[0] = apl >>>>>>> initializing paths from $PATH = /Users/alexeyv/Applications:/U >>>>>>> sers/alexeyv/Development/stm32tools:/Users/alexeyv/Developme >>>>>>> nt/arm-eabi-toolchain/arm-cs-tools-2012.03-56-e3f4013- >>>>>>> 20130413/bin:/Users/alexeyv/Development/gapl:/Users/ >>>>>>> alexeyv/.cabal/bin:/Users/alexeyv/Development/gradle-2. >>>>>>> 3/bin:/Users/alexeyv/Development/groovy-2.4.3/bin:/ >>>>>>> opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin: >>>>>>> /usr/local/bin:/usr/X11/bin:/Library/TeX/texbin >>>>>>> APL_bin_path is: /Users/alexeyv/Development/gapl >>>>>>> APL_bin_name is: apl >>>>>>> Reading config file >>>>>>> /Users/alexeyv/Development/gapl/etc/gnu-apl.d/preferences >>>>>>> ... >>>>>>> Reading config file /Users/alexeyv/.gnu-apl/preferences ... >>>>>>> Reading config file /Users/alexeyv/Development/gap >>>>>>> l/etc/gnu-apl.d/parallel_thresholds ... >>>>>>> Not reading config file >>>>>>> /Users/alexeyv/.config/gnu-apl/parallel_thresholds >>>>>>> (not found/readable) >>>>>>> 0 input files: >>>>>>> using ANSI terminal output ESC sequences (or those configured in >>>>>>> your preferences file(s)) >>>>>>> using ANSI terminal input ESC sequences(or those configured in >>>>>>> your preferences file(s)) >>>>>>> Using TCP socket towards APserver... >>>>>>> connecting to 127.0.0.1 TCP port 16366 failed. >>>>>>> (the first ::connect() to APserver is expected to fail, >>>>>>> unless >>>>>>> APserver was started manually) >>>>>>> Starting a new APserver listening on 127.0.0.1 TCP port 16366 >>>>>>> Found /Users/alexeyv/Development/gapl/APserver >>>>>>> Starting /Users/alexeyv/Development/gapl/APserver --port 16366 >>>>>>> --auto... >>>>>>> >>>>>>> connecting to 127.0.0.1 TCP port 16366 failed. >>>>>>> (::connect() should succeed eventually. This was attempt 1 >>>>>>> of 5) >>>>>>> connecting to 127.0.0.1 TCP port 16366 failed. >>>>>>> (::connect() should succeed eventually. This was attempt 2 >>>>>>> of 5) >>>>>>> connecting to 127.0.0.1 TCP port 16366 failed. >>>>>>> (::connect() should succeed eventually. This was attempt 3 >>>>>>> of 5) >>>>>>> connecting to 127.0.0.1 TCP port 16366 failed. >>>>>>> ::connect() to supposedly existing APserver failed: Invalid >>>>>>> argument >>>>>>> PID is 14426 >>>>>>> argc: 3 >>>>>>> argv[0]: 'apl' >>>>>>> argv[1]: '-l 37 --script --' >>>>>>> argv[2]: './aaa.apl' >>>>>>> stdin is: OPEN >>>>>>> uprefs.user_do_svars: 1 >>>>>>> uprefs.system_do_svars: 1 >>>>>>> uprefs.requested_id: 0 >>>>>>> uprefs.requested_par: 0 >>>>>>> Svar_DB not connected in Svar_DB::is_registered_id() >>>>>>> id.proc: 1001 at ProcessorID.cc:77 >>>>>>> Processor ID was completely initialized: 1001:0:0 >>>>>>> system_do_svars is: 1 >>>>>>> ┌→──────────────────────────────────────────┐ >>>>>>> │┌→──┐ ┌→─┐ ┌→─┐ ┌→───────┐ ┌→─┐ ┌→────────┐│ >>>>>>> ││apl│ │-l│ │37│ │--script│ │--│ │./aaa.apl││ >>>>>>> │└───┘ └──┘ └──┘ └────────┘ └──┘ └─────────┘│ >>>>>>> └∊──────────────────────────────────────────┘ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> However: >>>>>>> >>>>>>> >>>>>>> head -1 bbb.apl >>>>>>> #!/Users/alexeyv/Development/gapl/apl -l 37 --script -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> ./bbb.apl >>>>>>> sizeof(Svar_record) is 328 >>>>>>> sizeof(Svar_partner) is 28 >>>>>>> increasing rlimit RLIMIT_NPROC from 709 to infinity >>>>>>> >>>>>>> initializing paths from argv[0] = /Users/alexeyv/Development/gap >>>>>>> l/apl >>>>>>> initializing paths from $PWD = /Users/alexeyv/Sources/apl >>>>>>> APL_bin_path is: /Users/alexeyv/Development/gapl >>>>>>> APL_bin_name is: apl >>>>>>> Reading config file >>>>>>> /Users/alexeyv/Development/gapl/etc/gnu-apl.d/preferences >>>>>>> ... >>>>>>> Reading config file /Users/alexeyv/.gnu-apl/preferences ... >>>>>>> Reading config file /Users/alexeyv/Development/gap >>>>>>> l/etc/gnu-apl.d/parallel_thresholds ... >>>>>>> Not reading config file >>>>>>> /Users/alexeyv/.config/gnu-apl/parallel_thresholds >>>>>>> (not found/readable) >>>>>>> 0 input files: >>>>>>> using ANSI terminal output ESC sequences (or those configured in >>>>>>> your preferences file(s)) >>>>>>> using ANSI terminal input ESC sequences(or those configured in >>>>>>> your preferences file(s)) >>>>>>> Using TCP socket towards APserver... >>>>>>> connected to APserver, socket is 4 >>>>>>> using Svar_DB on APserver! >>>>>>> PID is 14455 >>>>>>> argc: 6 >>>>>>> argv[0]: '/Users/alexeyv/Development/gapl/apl' >>>>>>> argv[1]: '-l' >>>>>>> argv[2]: '37' >>>>>>> argv[3]: '--script' >>>>>>> argv[4]: '--' >>>>>>> argv[5]: './bbb.apl' >>>>>>> stdin is: OPEN >>>>>>> uprefs.user_do_svars: 1 >>>>>>> uprefs.system_do_svars: 1 >>>>>>> uprefs.requested_id: 0 >>>>>>> uprefs.requested_par: 0 >>>>>>> id.proc: 1001 at ProcessorID.cc:77 >>>>>>> Processor ID was completely initialized: 1001:0:0 >>>>>>> system_do_svars is: 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> - Here it hangs. >>>>>>> Here you see what depending on whether we have a full path in >>>>>>> the first >>>>>>> line command line arguments interpreted differently. Very odd. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Juergen Sauermann >>>>>>> <juergen.sauerm...@t-online.de> >>>>>>> <mailto:juergen.sauerm...@t-online.de> >>>>>>> writes: >>>>>>> >>>>>>> >>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> but then everything is just fine, isn't it? I believe in an >>>>>>>> earlier post you said that in OSX you don't see any output and >>>>>>>> have to type )OFF >>>>>>>> blindly (which suggest that you didn't have a working stdin)? >>>>>>>> >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> On 02/06/2017 05:53 PM, Alexey Veretennikov wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here are the results: >>>>>>>> >>>>>>>> sizeof(Svar_record) is 328 >>>>>>>> sizeof(Svar_partner) is 28 >>>>>>>> increasing rlimit RLIMIT_NPROC from 709 to infinity >>>>>>>> >>>>>>>> initializing paths from argv[0] = apl >>>>>>>> initializing paths from $PATH = /Users/alexeyv/Applications:/U >>>>>>>> sers/alexeyv/Development/stm32tools:/Users/alexeyv/Developme >>>>>>>> nt/arm-eabi-toolchain/arm-cs-tools-2012.03-56-e3f4013- >>>>>>>> 20130413/bin:/Users/alexeyv/Development/gapl:/Users/ >>>>>>>> alexeyv/.cabal/bin:/Users/alexeyv/Development/gradle-2. >>>>>>>> 3/bin:/Users/alexeyv/Development/groovy-2.4.3/bin:/ >>>>>>>> opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin: >>>>>>>> /usr/local/bin:/usr/X11/bin:/Library/TeX/texbin >>>>>>>> APL_bin_path is: /Users/alexeyv/Development/gapl >>>>>>>> APL_bin_name is: apl >>>>>>>> Reading config file >>>>>>>> /Users/alexeyv/Development/gapl/etc/gnu-apl.d/preferences >>>>>>>> ... >>>>>>>> Reading config file /Users/alexeyv/.gnu-apl/preferences ... >>>>>>>> Reading config file /Users/alexeyv/Development/gap >>>>>>>> l/etc/gnu-apl.d/parallel_thresholds ... >>>>>>>> Not reading config file >>>>>>>> /Users/alexeyv/.config/gnu-apl/parallel_thresholds >>>>>>>> (not found/readable) >>>>>>>> 0 input files: >>>>>>>> using ANSI terminal output ESC sequences (or those configured >>>>>>>> in your preferences file(s)) >>>>>>>> using ANSI terminal input ESC sequences(or those configured in >>>>>>>> your preferences file(s)) >>>>>>>> Using TCP socket towards APserver... >>>>>>>> connected to APserver, socket is 4 >>>>>>>> using Svar_DB on APserver! >>>>>>>> PID is 13743 >>>>>>>> argc: 3 >>>>>>>> argv[0]: 'apl' >>>>>>>> argv[1]: '-l 37 --script --' >>>>>>>> argv[2]: './aaa.apl' >>>>>>>> stdin is: OPEN >>>>>>>> uprefs.user_do_svars: 1 >>>>>>>> uprefs.system_do_svars: 1 >>>>>>>> uprefs.requested_id: 0 >>>>>>>> uprefs.requested_par: 0 >>>>>>>> id.proc: 1001 at ProcessorID.cc:77 >>>>>>>> Processor ID was completely initialized: 1001:0:0 >>>>>>>> system_do_svars is: 1 >>>>>>>> ┌→──────────────────────────────────────────┐ >>>>>>>> │┌→──┐ ┌→─┐ ┌→─┐ ┌→───────┐ ┌→─┐ ┌→────────┐│ >>>>>>>> ││apl│ │-l│ │37│ │--script│ │--│ │./aaa.apl││ >>>>>>>> │└───┘ └──┘ └──┘ └────────┘ └──┘ └─────────┘│ >>>>>>>> └∊──────────────────────────────────────────┘ >>>>>>>> >>>>>>>> >>>>>>>> Juergen Sauermann >>>>>>>> <juergen.sauerm...@t-online.de> >>>>>>>> <mailto:juergen.sauerm...@t-online.de> >>>>>>>> >>>>>>>> writes: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> i have added a check if stdin is open when GNU APL starts, SVN >>>>>>>> 881. >>>>>>>> >>>>>>>> If you start the following script: >>>>>>>> >>>>>>>> #!/usr/local/bin/apl -l 37 --script -- >>>>>>>> >>>>>>>> ]BOXING ¯8 >>>>>>>> ⎕ARG >>>>>>>> )off >>>>>>>> >>>>>>>> Then we can see if stdin is open on OSX and how apl is being >>>>>>>> called in OSX. >>>>>>>> >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> On 02/06/2017 11:21 AM, Juergen Sauermann wrote: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> yes. I changed it recently to fix the '--' issue. >>>>>>>> >>>>>>>> A GNU APL script assumes that it was called by execve(). The >>>>>>>> expand_argv() function >>>>>>>> "undoes" the behavior of execve(), which lumps together all >>>>>>>> arguments on the first script line >>>>>>>> into argv[1] of GNU APL's main(argc, argv) functions. In that >>>>>>>> process the filename of the script >>>>>>>> gets lost (or may not even exist, e.g. in a pipe) so -f could >>>>>>>> be used to tell the script where to >>>>>>>> fetch its input. This is because execve() had already closed >>>>>>>> the file descriptor before it called >>>>>>>> apl, so apl has no stdin when it starts. With -f you point >>>>>>>> apl to re-open the input file again. >>>>>>>> >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> On 02/05/2017 09:24 PM, Alexey Veretennikov wrote: >>>>>>>> >>>>>>>> Ok, as I understand I need to take a look at >>>>>>>> UserPreferences::expand_argv >>>>>>>> and >>>>>>>> UserPreferences::is_APL_script >>>>>>>> >>>>>>>> correct? >>>>>>>> >>>>>>>> Juergen Sauermann >>>>>>>> <juergen.sauerm...@t-online.de> >>>>>>>> <mailto:juergen.sauerm...@t-online.de> >>>>>>>> writes: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> yes, most of this trouble is caused by how execve() works, >>>>>>>> which is quite different >>>>>>>> on different platforms. And it happens before apl is being >>>>>>>> called so I cant do much >>>>>>>> about it. >>>>>>>> >>>>>>>> Sometimes it helps to start apl with -f so that the interpreter >>>>>>>> knows where to fetch >>>>>>>> its input, like: >>>>>>>> >>>>>>>> #!/usr/local/bin/apl -f /home/eedjsa/tmp/script --script -- >>>>>>>> >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> On 02/04/2017 02:00 PM, Alexey Veretennikov wrote: >>>>>>>> >>>>>>>> Hi Juergen, >>>>>>>> >>>>>>>> Something is apparently strange on OSX(?). With the latest >>>>>>>> version >>>>>>>> when I run the same script below I get the silent input without >>>>>>>> echoing, no output like below, and I have to blindly type )off >>>>>>>> manually >>>>>>>> to exit interpreter. >>>>>>>> >>>>>>>> >>>>>>>> Juergen Sauermann >>>>>>>> <juergen.sauerm...@t-online.de> >>>>>>>> <mailto:juergen.sauerm...@t-online.de> >>>>>>>> writes: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> I have changed the handling of command line options, SVN 877. >>>>>>>> >>>>>>>> It now works like this: >>>>>>>> >>>>>>>> script: >>>>>>>> >>>>>>>> #!/usr/local/bin/apl --script -- >>>>>>>> >>>>>>>> )copy 5 FILE_IO FIO∆errno >>>>>>>> 8⎕CR ⎕ARG >>>>>>>> )off >>>>>>>> >>>>>>>> output: >>>>>>>> >>>>>>>> eedjsa@server66:~/tmp$ ./script scriptarg >>>>>>>> DUMPED 2017-01-28 22:57:44 (GMT+1) >>>>>>>> ┌→──────────────────────────────────────────────────────────┐ >>>>>>>> >>>>>>>> │┌→─────────────────┐ ┌→───────┐ ┌→─┐ ┌→───────┐ >>>>>>>> ┌→────────┐│ >>>>>>>> ││/usr/local/bin/apl│ │--script│ │--│ │./script│ │scriptarg││ >>>>>>>> │└──────────────────┘ └────────┘ └──┘ └────────┘ >>>>>>>> └─────────┘│ >>>>>>>> └∊──────────────────────────────────────────────────────────┘ >>>>>>>> >>>>>>>> >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> On 02/03/2017 11:06 PM, Alexey Veretennikov wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yes ./script -- myarg works. >>>>>>>> >>>>>>>> The problem is why I have to repeat -- in command line since >>>>>>>> I've >>>>>>>> already specified it in the first line of the script, as it is >>>>>>>> specified >>>>>>>> in documentiation. >>>>>>>> >>>>>>>> Basically I would like to pass my arguments to the script >>>>>>>> without >>>>>>>> mentioning "--" in the command line. >>>>>>>> >>>>>>>> Juergen Sauermann >>>>>>>> <juergen.sauerm...@t-online.de> >>>>>>>> <mailto:juergen.sauerm...@t-online.de> >>>>>>>> >>>>>>>> writes: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> how about this: >>>>>>>> >>>>>>>> *eedjsa@server66:~/tmp$ ./script -- arg** >>>>>>>> **DUMPED 2017-01-28 22:57:44 (GMT+1)** >>>>>>>> **┌→────────────────────────────────────────────────────┐** >>>>>>>> **│┌→─────────────────┐ ┌→───────┐ ┌→───────┐ ┌→─┐ ┌→──┐│** >>>>>>>> **││/usr/local/bin/apl│ │--script│ │./script│ │--│ │arg││** >>>>>>>> **│└──────────────────┘ └────────┘ └────────┘ └──┘ └───┘│** >>>>>>>> **└∊────────────────────────────────────────────────────┘* >>>>>>>> >>>>>>>> There is no point (and it does not work) to put the arguments >>>>>>>> in the first line >>>>>>>> of the script, >>>>>>>> because if the script itself knows them then the rest of the >>>>>>>> script can use them >>>>>>>> as well. >>>>>>>> >>>>>>>> *⎕ARG *is what is passed to the script, not what is passed to >>>>>>>> the interpreter >>>>>>>> mentioned in the script. >>>>>>>> See also *man execve*. >>>>>>>> >>>>>>>> /// Jürgen >>>>>>>> >>>>>>>> >>>>>>>> On 02/03/2017 08:29 PM, Alexey Veretennikov wrote: >>>>>>>> >>>>>>>> Given the following script: >>>>>>>> ------------------------------------------ >>>>>>>> #!apl --script -- >>>>>>>> )copy 5 FILE_IO FIO∆errno >>>>>>>> 8⎕CR ⎕ARG >>>>>>>> )off >>>>>>>> ------------------------------------------ >>>>>>>> when I try to run it like >>>>>>>> >>>>>>>> ./script.apl myarg >>>>>>>> >>>>>>>> I get the error: >>>>>>>> >>>>>>>> /script.apl myarg >>>>>>>> unknown option 'myarg' >>>>>>>> ... >>>>>>>> >>>>>>>> This happens on 833 and 1.5 and on both linux and osx. >>>>>>>> >>>>>>>> In INFO file it explicitely states: >>>>>>>> >>>>>>>> "Using ’—-’ as last argument on the first line of the script >>>>>>>> file >>>>>>>> prevents any of the options given to the script to be >>>>>>>> interpreted as APL >>>>>>>> options; all such options are passed to the application via >>>>>>>> ⎕ARG." >>>>>>>> >>>>>>>> But it is not happening. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>
