the README.md example

[coderofsalvation]

@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?

[fcard]

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?

[coderofsalvation]

thx i will put that in the docs as well. and agreed, spaceseparated is actually more shell-ish. Could you get the json_parser to work concerning the json provided in the README.md?

Maybe newlines are the bottleneck?

kind regards,

Leon

ps. JSON is important in that sense that its the most populair text-serializable format these days. Its a big plus to be able to extract some values (in bash) without having to install jq or a complete programming language (think embedded lowend devices). Thanks to your efforts this is possible now :)

On Tue, Aug 28, 2018, 22:35 fcard [email protected] wrote:

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 becho $x #> 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?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/coderofsalvation/powscript/issues/50#issuecomment-416731257, or mute the thread https://github.com/notifications/unsubscribe-auth/AAK_ZNu9WwGjDU7VSMes0y2rNMW-Q2AXks5uVal9gaJpZM4WPQIG .

[coderofsalvation]

btw i really like your ${foo.bar} proposal, but i also agree that for now the current solution is good enough. it'll be a nice in the longterm.

On Wed, Aug 29, 2018, 09:54 Leon van Kammen [email protected] wrote:

thx i will put that in the docs as well. and agreed, spaceseparated is actually more shell-ish. Could you get the json_parser to work concerning the json provided in the README.md?

Maybe newlines are the bottleneck?

kind regards,

Leon

ps. JSON is important in that sense that its the most populair text-serializable format these days. Its a big plus to be able to extract some values (in bash) without having to install jq or a complete programming language (think embedded lowend devices). Thanks to your efforts this is possible now :)

On Tue, Aug 28, 2018, 22:35 fcard [email protected] wrote:

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 becho $x #> 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?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/coderofsalvation/powscript/issues/50#issuecomment-416731257, or mute the thread https://github.com/notifications/unsubscribe-auth/AAK_ZNu9WwGjDU7VSMes0y2rNMW-Q2AXks5uVal9gaJpZM4WPQIG .

[fcard]

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"

[coderofsalvation]

works! Thanks again :)

I think i will put a stripped version of this snippet into README.md (to make an attractive skimmable README.md) and link to this snippet as the full example (will also demonstrate multiple arguments in there).

Documentation is getting more and more in sync with the new compiler...ITS HAPPENING

On Thu, Aug 30, 2018 at 12:59 AM fcard [email protected] wrote:

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 a third thing is that 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 https://github.com/coderofsalvation/powscript/pull/52)

require 'json' require_cmd 'curl'

usage(app) local example_url="https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json" echo " $app --url 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"

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/coderofsalvation/powscript/issues/50#issuecomment-417134136, or mute the thread https://github.com/notifications/unsubscribe-auth/AAK_ZCHuvrj4RB2SLsqTCEi2bEM0MrBqks5uVxy1gaJpZM4WPQIG .

-- /WEBSITE 2wa.isvery.ninja /MOBILE +31 6 13499604 /LOCATION Netherlands, Drachten. Hongarije, Budapest. /COMPANYNR. 08124656 /TAGS Web & New Media consultancy driven by Opensource, Google tech & a teaspoon of javascript.

[fcard]

Heehee. Maybe we could add an examples directory to have this and more like it readily available in the repo.

[coderofsalvation]

yep, that's a great idea actually.

On Thu, Aug 30, 2018 at 6:18 PM fcard [email protected] wrote:

Heehee. Maybe we could add an examples directory to have this and more like it readily available in the repo.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/coderofsalvation/powscript/issues/50#issuecomment-417378461, or mute the thread https://github.com/notifications/unsubscribe-auth/AAK_ZAZqWJx_lSNm2w4CouS0YrAXzrcOks5uWBBegaJpZM4WPQIG .

-- /WEBSITE 2wa.isvery.ninja /MOBILE +31 6 13499604 /LOCATION Netherlands, Drachten. Hongarije, Budapest. /COMPANYNR. 08124656 /TAGS Web & New Media consultancy driven by Opensource, Google tech & a teaspoon of javascript.

[fcard]

There are a few more things that need fixing in the readme:

• Command Line Options: you can use powscript --help to 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

[fcard]

(oh, and the --interactive flag is now assumed when there are no other arguments, since that's how all interactive languages I know work)

[fcard]

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.

[coderofsalvation]

hm i guess it needs a bit more work. My aim was to :

• keep the 'look how easy it is'-snippet around max 15 lines.
• attract newbie shellscripters (who are about to learn bash)
• attract the interest of seasoned shellscripters
• keep the README.md relatively short by using links to markdown-files in /doc

The question is maybe: given the above context, what is the subset of features we want to show off. Imho visitors should be able to skim thru README.md's, and feel like 'oh I get this, this makes writing bash much easier'.

Leon

On Thu, Aug 30, 2018 at 7:49 PM fcard [email protected] wrote:

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/coderofsalvation/powscript/issues/50#issuecomment-417408428, or mute the thread https://github.com/notifications/unsubscribe-auth/AAK_ZMAwYWCzrPIqpXDAj-8aM-9hoEr5ks5uWCWUgaJpZM4WPQIG .

-- /WEBSITE 2wa.isvery.ninja /MOBILE +31 6 13499604 /LOCATION Netherlands, Drachten. Hongarije, Budapest. /COMPANYNR. 08124656 /TAGS Web & New Media consultancy driven by Opensource, Google tech & a teaspoon of javascript.

[fcard]

The new example is way better, I really like it! The only suggestions I have (I keep finding things to nitpick, sorry ;-;) are:

1. Since you already require the HOME variable, why not have require_env 'HOME' instead of require_env 'TERM'?
2. You could change run(@args -- foo) to run(@args -- description), it makes the argument more descriptive. (in two ways!) You could then also change the usage to please pass (--description|-d) <string>, to demonstrate that keyword args also have shortcut versions.