On 2020-07-16 01:45, ethiejiesa via Programming wrote:
This is definitely a lateral thinking approach. I don't have access to
JQt, but
more to the point, I want this to be usable just like any other CLI
program.
Partly, I am looking at if/how J can be used as a replacement for shell
scripts, sed, awk etc.
The big limitation is interactive input. Consider an executable
file named 'howdy' (which assumes you have 'j' in your path
that starts jconsole. It might be called 'jconsole' or
'ijconsole' instead)
#! /usr/bin/env j
echo 'How''s your day going?'
(1!:1 ] 1) fappends 'days.log'
exit 0
Intent: you run ./howdy , you get asked how your day is, you
reply interactively, and then your answer is logged. Like so:
$ ./howdy
How's your day going?
well
$ cat days.log
well
But if you run it, this happens instead:
$ ./howdy
How's your day going?
well
|value error: well
+/i.10
45
NB. what happened?
exit 0
$ cat days.log
exit 0
Instead of getting your input, 1!:1 read in the next line of
the script itself, and then - the script not exiting with this
line skipped - you're left with an interactive j session.
OK, so file 1 is the script itself. This is slightly
unfortunate already because file 1 is what you would use
interactively, in a J session rather than a script, so you now
need to change your code when you use it in a script. But
there's another file, 3:
$ ./howdy
How's your day going?
well
...
?
hello?
exit
OK I'm going to hit ctrl-D to end this stream
$ cat days.log
exit 0
well
...
?
hello?
exit
With this change you get the correct stream but you're reading
in the entire stream instead of a single line. This is actually
a workable way to read input, if the user hits 'enter' then
'ctrl-D' every time, but it's certainly not how shell
scripts/awk normally work.
Provided you can avoid interactive input, I quite like J as a
scripting language. I especially like how easy it is to skip
the 'exit 0' and continue interactively with the script's
environment.
... which is also a problem for CGI scripts, since stdin is
untrusted input. If it's possible to cause an error in your
script, and if your script becomes interactive on error, then
you potentially have a backdoor in your website for commands
like
'H4cked by _-*^ j-Crewz ^*-_' fwrites '../index.html'
Which is already embarrassing to read, let alone see as your
new homepage.
But, web services needing a lot of extra care is nothing new,
and interactive input in my experience is very rarely wanted
anyway as it makes scripts hard to reuse in other scripts.
Here's a slightly more realistic day-logger:
#! /usr/bin/env j
LOG=:]`('days.log'"_)@.(0&-:) getenv 'DAYLOGPATH'
usage=:3 : 'exit 1 [ echo ''Usage: '', (1{::y), '' <your day>'''
logit=:3 : 'LOG fappends~ (6!:0 ''YYYY-MM-DD ''), '' '' joinstring
2}.y'
usage`logit @.(2 < #) ARGV
exit 0
As used:
$ ./myday
Usage: ./myday <your day>
$ ./myday doing well thank you
$ ./myday simulated better day tomorrow # edit the log
$ DAYLOGPATH=bad-days.log ./myday "should've stayed in bed"
$ cat days.log
2020-07-16 doing well thank you
2020-07-17 simulated better day tomorrow
$ cat bad-days.log
2020-07-16 should've stayed in bed
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
