|
| From: | Juergen Sauermann |
| Subject: | Re: [Bug-apl] strange behavior of -- |
| Date: | Tue, 7 Feb 2017 12:54:52 +0100 |
| User-agent: | Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 |
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, EliasOn 7 February 2017 at 19:21, Juergen Sauermann <address@hidden <mailto:address@hidden>> 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<address@hidden> <mailto:address@hidden> 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<address@hidden> <mailto:address@hidden> 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:/Users/alexeyv/Development/stm32tools:/Users/alexeyv/Development/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/gapl/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/gapl/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/gapl/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 <address@hidden> <mailto:address@hidden> 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:/Users/alexeyv/Development/stm32tools:/Users/alexeyv/Development/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/gapl/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 <address@hidden> <mailto:address@hidden> 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 <address@hidden> <mailto:address@hidden> 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 <address@hidden> <mailto:address@hidden> 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: address@hidden:~/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 <address@hidden> <mailto:address@hidden> writes: Hi Alexey, how about this: address@hidden:~/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.
| [Prev in Thread] | Current Thread | [Next in Thread] |