Hi Elias,
I believe *--rawCIN* plus *--noColor *would be the equivalent of
*--rawCOUT*.
*--rawCIN*, despite of its name, **primarily affects the output by not
sending escape sequences for positioning the cursor when the interpreter
needs input. The only other escape sequences that I recall a
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 y
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 subs
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> 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
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 th
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
Hi,
Yes exactly, I was using zsh!
Xiao-Yong Jin writes:
> 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 w
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:
SC
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: e
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
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) is328
sizeof(Svar_partner) is 28
increasing rlimit RLIMIT_NPROC from 709 to infinity
initializing paths from a
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
Hi,
Here are the results:
sizeof(Svar_record) is328
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/Develo
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
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
do you have an example of what you mean by 'used in this way'?
with the recent '--' change - the apl scripting seems to behave the same as
would be done with python/php
On Sun, 05 Feb 2017 21:08:40 +0100
Alexey Veretennikov wrote:
> Hi,
>
> It looks like other interpreters (not APL, but
Ok, as I understand I need to take a look at
UserPreferences::expand_argv
and
UserPreferences::is_APL_script
correct?
Juergen Sauermann 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
Hi,
It looks like other interpreters (not APL, but other languages: perl,
python, awk etc) have some other behavior concerning command line
arguments.
With python I can just specify
#!/usr/bin/python
and the script will pick-up all arguments an ordinary program,
regardless of the platform; while
yes of course :)
BUILDTAG:
-
Project:GNU APL
Version / SVN: 1.6 / 877M
Build Date: 2017-02-04 16:55:46 UTC
Build OS: Linux 2.6.32.71 i686
config.status: unknown configure options
Archive SVN: 872
/usr/src/apl/apl-877 > l /usr/local/bin/apl
-r
Hi
the -- is strill required on the cliscript -- arg1 arg2 for 877 i
don't see what was really changed
script is
#! /usr/local/bin/apl --script --
⊃⎕ARG ⍝ show command line options
)off
script arg1 arg2
unknown option 'arg1'
usage: apl [options]
options:
this use to wo
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
th
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 writes:
> Hi Alexey,
>
> I have changed
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
personally i would rather have the -- in the script being observed rather
then having to do it like./script -- arg1 arg2
should be consistent with how other scripting languages handle command line
arguments/parameters
On Fri, 03 Feb 2017 23:06:38 +0100
Alexey Veretennikov wrote:
> Hi,
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.
J
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││**
**│└
26 matches
Mail list logo
