the current release (1.1.1) does not yet expose the bashy variant. i'll do that for 1.2.0, it's ready to go, i just haven't had a chance to include it in the dist bundles.
for 1.1.1, you can use the `run` command from within the Shell. this will execute a sequence of Shell commands from a file. prior to 1.1.1, we didn't expose the `run` command even in the Shell. we're getting there, especially with all of the great feedback we're getting. keep it coming!! nick @starpit On Fri, Aug 4, 2017 at 2:46 PM, Tyson Norris <tnor...@adobe.com.invalid> wrote: > I didn’t get that it can be invoked from a shell in a REPL style, thanks - > is this possible with the current downloads? > > I appreciate the value of the UI (looks great btw!) - its just not clear > how to do the 'scripted execution’ parts? > Thanks > Tyson > > > On Aug 4, 2017, at 11:22 AM, Nick Mitchell <moose...@gmail.com> wrote: > > > > thanks tyson! > > > > the tool can indeed be used in a purely bashy way, if that's helpful. so > > e.g., the following works, assuming for a second that we call the Shell > > `wsker` for the purpose of this email: > > > > wsker activation get foo > > wsker action invoke foo > > wsker activation get xxxx > > > > these look familiar, i think? hehe, what i'm getting at is that the > command > > set overlaps! and you can issue one-off commands to the Shell directly > from > > bash, if you'd like; or in a bundle via `wsker script.txt` > > > > i propose that you will quickly discover the value of having the electron > > app, including: > > > > 1) your command history is specific to openwhisk, so you don't have to > > arrow up past non-whisk commands > > 2) the command set is richer > > 3) you get visuals for the common and important data > > 4) no more copy-paste of that xxxx part of wsk activation get! > > 5) an app to itself, with its own icon and one that can be separately > > minimized/maximized, or pinned to desktops > > > > > > nick > > @starpit > > > > On Fri, Aug 4, 2017 at 12:23 PM, Tyson Norris <tnor...@adobe.com.invalid > > > > wrote: > > > >> Some thoughts on this: I think one thing that would make this less > >> confusing is introducing a REPL to the wsk CLI (or a wrapper of it) > instead > >> of introducing REPL as “a desktop application with a gui”. I like the > gui, > >> but I also think it may be adding a layer of confusion. > >> > >> Similarly, it should be carefully considered how commands can be > >> consistent between REPL and non-REPL usage, e.g. for related CLI auth > >> discussion, it would be great if: > >> wsk auth > >> Had the same effect as: > >> REPL: auth > >> > >> The difference being that wsk auth would store credentials to disk for > use > >> at next wsk command run, and REPL: auth would store credentials for the > >> length of the session only. In addition, the REPL may be able to > >> conveniently pop up an auth dialog, where the CLI may have to ask you to > >> load a url, but the end result would be the same. > >> > >> From there the notion of “REPL has a special language in addition to the > >> CLI commands” is something easier (at least for me) to get behind, as > long > >> as things that are not purely session-based are added to the CLI as well > >> (like auth flavored commands). > >> > >> Thanks for starting this tool, I think its useful and look forward to > >> watching it progress! > >> > >> Tyson > >> > >> > >> > >> > >>> On Aug 4, 2017, at 8:59 AM, Nick Mitchell <moose...@gmail.com> wrote: > >>> > >>> With the shell, one would issue `last`. Or `last foo`. With a REPL, we > >> have > >>> the luxury of a flexible command structure that can be tailored to the > >> task > >>> at hand. > >>> > >>> And, once you are looking at that activation, you can drill down (eg to > >>> tree view of the sequence), or reinvoke (we can remember the input), or > >>> reinvoke with new args, or add this action to a sequence now that you > >> know > >>> it works (append to myseq). > >>> > >>> These are all plugins, so new ideas can appear as shell commands in a > >>> matter of minutes. > >>> > >>> On Aug 4, 2017 11:49, "Rodric Rabbah" <rod...@gmail.com> wrote: > >>> > >>>> This is a very useful discussion - thank you Rob for starting it. We > >> both > >>>> want and need this kind of feedback! > >>>> > >>>> One of the observations that you noted wrt to the shell is that it has > >> "its > >>>> own language". Indeed there is a language here, in the same way that > the > >>>> wsk CLI already offers a language for serverless programming using > >>>> OpenWhisk. When the language of the CLI is limiting, what do we do as > >>>> developers? I posit that we layer new languages on top --- my favorite > >>>> example is "give me the last activation". At one point I polled for > how > >>>> many bash aliases the community has come up with for this feature! > >> Recently > >>>> the wsk CLI added `wsk activation get --last`. That's still too > verbose > >> and > >>>> I continue to use my local alias for this command and I expect others > >> will > >>>> too. More concretely, it's too verbose when I'm developing, iterating, > >> and > >>>> debugging. > >>>> > >>>> In the same way, I've seen developers share bash scripts for > automating > >>>> other tasks that the current wsk CLI (or really any client) doesn't > yet > >>>> support. For example: deleting all assets in a namespace, or a > package. > >>>> These are features I expect will eventually end up in the wsk CLI. But > >> the > >>>> gate for rapidly experimenting with new aliases, plugins, features is > >> too > >>>> narrow today. > >>>> > >>>> The "openwhisk shell" is a way of normalizing the programming > experience > >>>> for serverless - it does subsume the CLI in that the wsk commands > should > >>>> work inside it, but also extends the capabilities to add more > syntactic > >>>> convenience and make a workflow more fluid - some of these may not be > >>>> readily possible or practical in a terminal. One of the benefits that > >> I've > >>>> experienced directly is that it makes the iterative programming > >> experience > >>>> and development for serverless more agile and fluid. > >>>> > >>>> To me, this is independent of the question of scripting for > deployment, > >>>> continuous integration, and delivery and hence the context for my "old > >>>> school" comment - the shell can export a bash script for you, or other > >>>> artifacts like a serverless framework manifest, for managing a > >> deployment > >>>> (as examples). > >>>> > >>>> -r > >>>> > >> > >> > >
