Open naturallymitchell opened 5 years ago
from discussion on Discord
torchbear
can be a decent Lua interpreter.
Linux has a cool feature named shebang: https://en.wikipedia.org/wiki/Shebang_(Unix)
#!/bin/sh
printf 'Hello, %s!\n' 'Found Patterns Studio'
Shebang line can contain any program:
#!/bin/echo
If we save this file in /usr/bin/myapp and run it, it will output:
$ myapp
/usr/bin/myapp
$
$ myapp 123
/usr/bin/myapp 123
So, what happens under the hood:
/usr/bin/echo /usr/bin/myapp 123
^ ^ ^
| | |
| | arguments from command line
| full path to `myapp`
shebang line
The torchbear
shebang may look like this:
#!/usr/bin/torchbear --run
--[[
Here follows Lua code
--]]
And the actual call will be:
$ /usr/bin/torchbear --run filename [argument...]
So the actual implementation will require a new command line flag (like --run
), that will specify location of Lua file to run. When the flag is provided torchbear
should use all non-option arguments to create a Lua global array arg
similar to standard Lua interpreter.
Also torchbear
should set Lua include path to dirname of the command passed in --run
flag. One caveat here is that the provided command may be a link (very common to place links into PATH directories). Then torchbear
should dereference it before setting the include path.
Torchbear installs to different paths depending on the platform, so I believe this will help: Shell script shebang for unknown path
Yeap, sure. The env
trick will work as well.
After some research turns out we can't use the --run
option:
When setting shebang line to #!/usr/bin/env torchbear --run
and running it, the output is:
$ LANG= sample-torch
/usr/bin/env: 'torchbear --run': No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
$
env
receives torchbear --run
as a single argument. The proposed -S
option is not standard and won't work on non GNU env
implementation.
We can drop the --run
flag and start torchbear
in CLI mode, when there is at least one non-option value in the arguments:
torchbear -a 1 -b 2 /file/to/run
Here /file/to/run
is first non option argument. All arguments that follow it (including itself) must be passed to Lua via arg
global. The Lua package.path
must be set as well.
This way the final shebang line will be:
#!/usr/bin/env torchbear
Sounds good
Oh, and we should not forget about --
thing.
Huh
Quote from POSIX Utility Conventions:
Guideline 10: The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
it seems like we should completely switch to #!/usr/bin/env torchbear
, where possible, instead of expecting to call torchbear
directly on an app. this is just like using python
and lua
, ie any scripting language.
so we just need https://github.com/foundpatterns/torchbear/issues/19, which seems pretty doable, to make torchbear really light up
@sineemore how hard do you think this issue will be?
Depends on the argument parsing.
I don't know much about clap
, maybe @dariusc93 can suggest a thing.
Most part of required code was written in pull request I've closed recently. I guess it only lacks the proper argument parsing and setting command arguments in Lua arg
global table. Doable things.
And REPL is completely another kind of beast. But yet again, since there is a pure Lua implementation I don't think it's a hard thing.
can way-cooler's clap ArgMatches help us?
torchbear
can be a decent Lua interpreter.
I took this for granted. this is its first first killer app
Relevant pull request: https://github.com/foundpatterns/torchbear/pull/158
Implemented in https://github.com/foundpatterns/torchbear/pull/158
gut
showed, thenmp
followed in using bash scripts, which as Sharaf puts it is EVIL I agree we need something robust I personally like config files but we're gonna put these apps system-wide, starting with mp so are they goin in with bash?