Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

argument passing #13

Open
matthewmueller opened this issue Aug 14, 2014 · 7 comments
Open

argument passing #13

matthewmueller opened this issue Aug 14, 2014 · 7 comments

Comments

@matthewmueller
Copy link

I'm not sure if this is the direction you'd want to go with this project, but this sentence caught my attention:

Also since it's written in Go it's very simple to curl the binary on to any existing system.

That basically means, I could spin up a brand new ubuntu server on AWS, curl and run this right?

I think this could be more than a provisioning tool with argument passing. You could do something like:

stack scripts/release.go <version>

You get all the benefits of a modern language with the power of bash.

Again possibly out of scope, but it got me thinking :-D

@tj
Copy link
Member

tj commented Aug 22, 2014

yeah I was thinking about making it a more generic shell-like language, I have mixed feelings on that since it's already (and will probably be more so) geared towards provisioning. I want to add variable support so that {foo} if not defined will prompt if it's missing or require that you pass --foo bar. Otherwise yup just curl it and run

@matthewmueller
Copy link
Author

<3 {foo} prompting if no input, that'd be awesome.

@tj
Copy link
Member

tj commented Aug 23, 2014

I want to change up the DSL (or lack of) quite a bit actually haha, might warrant doing a little interpreted language, stack will just be ship with that lang included and a bit of a runtime so it has the nice logging etc

@matthewmueller
Copy link
Author

digging the Dockerfile style commands, but what do you have in mind?

@tj
Copy link
Member

tj commented Aug 23, 2014

yea I like that too, I guess it's really just fancier set -e at the moment, which itself is pretty sweet for provisioning haha, sucks that the rest of shell scripting is so horrid. I just figure if I'm going to be adding non-shell directives for other things I might as well just make a new language I suppose.

I mostly just don't want to use Ruby or Python haha too much of a clusterfuck, shell is close but not expressive enough. Shell is pretty fucked though not sure I want to go down the road of supporting "native" shell commands with redirection and all that junk haha

@matthewmueller
Copy link
Author

Shell has awful composition too. you can't include a function and use it later, so it's really annoying breaking up your files.

@tj
Copy link
Member

tj commented Aug 23, 2014

yeah I have to say pretty much the only thing I like about shell scripts is that commands are first-class haha that's about it, foo(){} is a pretty nice syntax too but referencing args via positional vars is lame

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants