the README.md example
coderofsalvation opened this issue · 12 comments
@fcard I've modified the README.md example to get it to work again. It almost works again, except for printing the version-property of a parsed json-object.
What were your initial ideas on this?
Array-notation or dot-notation to reference (nested) properties?
Currently, you can get values like so:
X={}
json_parse X '{"a": {"b": 1}}'
json_print X a b #> 1
json_value ${y:ref} X a b
echo $y #> 1 I think we could add some syntactic sugar, but I dunno about making them either $obj[prop] or obj.prop.
The first makes things a lot complicated, since we would need to differentiate between normal arrays and json arrays, as they differ in semantics quite a bit.
Making it obj.prop would make it difficult to use strings with dots in them, and in general I don't think it mixes well with the rest of the language.
We could make it something like ${obj.prop}, but is json that important that we need syntax for it?
I took a look at the readme example and found out a few bugs in the json parser (all of which I have now fixed), and also realized that the compiled script doesn't have the shebang at the start, which is very annoying.. and we can't pass command line arguments to powscript file, also very annoying. They should be easy enough to fix, through.
With that out of the way, how about this for the example? (which uses the vararg feature I am proposing in #52)
require 'json'
require_cmd 'curl'
usage(app)
local example_url="https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json"
echo "
$app <json keys...> --url <json file>
Description:
obtains and parses the json file given by the url,
then prints the data corresponding to the received keys.
Examples:
$app version --url '$example_url'
$app repository type --url '$example_url'
$app repository url --url '$example_url'
"
run(@keys -- url)
if empty? url
echo "Usage: $(usage myapp)"; exit
data={}
json=$(curl -s $url)
json_parse data "$json"
json_print data $keys[@]
run $@Which we should be able to run like this:
powscript myapp.pow version --url "https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json"
But right now, we can do:
powscript -c myapp.pow -o myapp.bash
bash myapp.bash version --url "https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json"
Heehee. Maybe we could add an examples directory to have this and more like it readily available in the repo.
There are a few more things that need fixing in the readme:
- Command Line Options: you can use
powscript --helpto check the updated options. - Interactive Mode: I now consider it robust enough to not be experimental anymore, plus the output looks different now.
- Posix Mode: Powscript now does its own checking to identify unsupported features, plus I want to eventually allow all features to work in it, even arrays ;P
I will let you handle those while I focus on porting my fork's PRs to here, and maybe later I will send some more nitpicky suggestions :P
(oh, and the --interactive flag is now assumed when there are no other arguments, since that's how all interactive languages I know work)
Your example is a bit confusing in what it's supposed to be... I get you're showing off features, but to me it's very distracting.
The new example is way better, I really like it! The only suggestions I have (I keep finding things to nitpick, sorry ;-;) are:
- Since you already require the
HOMEvariable, why not haverequire_env 'HOME'instead ofrequire_env 'TERM'? - You could change
run(@args -- foo)torun(@args -- description), it makes the argument more descriptive. (in two ways!) You could then also change the usage toplease pass (--description|-d) <string>, to demonstrate that keyword args also have shortcut versions.