How about shjs -c? shl is kind of far from shelljs and is too similar IMO to the SHift Left instruction.

Yeah, you're right. My goal was to make it work without too much typing for providing a good alternative to bash commands in npm "inline" scripts where you often chain multiple commands together.
Let's ask some other people also cc @arturadib @keithamus @anselmh @dandv @tobiastom

I actually don't really have any preference on any approach. I think the shl one is clearer because the options would not get mixed in execution (e.h. is the -c for shjs or rm)

Thanks @nickdima for working on this. Really looking forward to this!

@nfischer: Thoughts?

@nickdima thanks! This looks great, and I'm sure a lot of people would appreciate this.

1. Could you add a couple tests?
2. Once Implementing error codes and adding the errorCode() function #269 is merged (hopefully soon), could you address my comment above?

@ariporad what are your thoughts on shl vs shjs -c vs something else?

@tobiastom said:

I think the shl one is clearer because the options would not get mixed in execution (e.h. is the -c for shjs or rm)

Valid concern, but if we are to stick with the semantics of sh it should be clear from the position of -c that it describes the one that precedes that.

Wow, I did this 4 months ago so I had to get back into context :)
Thanks for the suggestions @nfischer
So... shl or shjs -c ?

@nickdima my vote would have to be for shjs -c. It most closely follows bash -c, python -c, etc. Let's see what @ariporad's thoughts are though.

And sorry about the delay! We'll be trying to get back on top of the PRs and issues. Thank you for your contribution!

I like -c. It makes the most sense to me.
We could also consider -e, like node -e

@nickdima would you be able to refactor this into the shjs script, and have it be activated by the -c flag (or -e, if you prefer)?

I suppose the only concern is if users get confused by whether to write:

$ shjs -c rm -rf foo

or

$ shjs -c "rm('-rf', 'foo')"

Well, the second would be correct. I guess just throw an error for the
first?

@ariporad the way this is written, the first would be correct actually. The second is not supported (hence why I think it's slightly confusing).

@nfischer: Hmm...

That actually makes me less sure if we should do this. Now that I think about it, I'm not sure if we should be encouraging embedding shell scripts as js inside package.json. And the way it's implemented now is very confusing. (Its just an incomplete, non-compliant implementation of bash).

So I'm not sure about this, maybe modules like 'mkdirp' or 'rimraf' are just the way to go.

@ariporad this comes from #202, which seems like a popular issue. It sounds like this is along the lines of what users want.

I don't think the bash syntax is necessary, but it does make porting extremely easy, I suppose.

@nfischer: Hmm...
What are your thoughts on pulling it in to it's own module, which could depend on shelljs? (It could be under the shelljs org). I just feel like it's really out of scope.

@ariporad I'm ok with making it its own module.

@nfischer: Sounds great!
@nickdima: Would you mind if I re-packaged this into its own module?

Everyone, what should we call it? I like jsh, which can either stand for Javascript Shell or it can be a contraction of JS and SH. Although that's not available on npm... Thoughts?

jsh is already used by other projects too: https://code.google.com/archive/p/jsh/ (which is also a "JavaScript SHell." How about jsbox (after busybox)? It has a similar syntax of busybox <applet> [args...]

or just shelljs-cli :)

@ariporad I'm ok with you repackaging it as a new module, maybe it's better that way
let's make sure we keep the exposed bin script's name just a few letters

@ndelitski: Ok, Thanks!

Anyone have any naming ideas? (sh-c?)

I vote against sh-c. That's one space off from sh -c, which has a very different meaning

Ok everyone, I have a bad idea: What about xec or xek, short for exec. (Yes, I know both of those are terrible, but they're 3 letters, free on npm, and mostly describe what they do).

Actually, that gives me a better idea: What about xsh? (Also free on npm).

I actually like shx, which is also vacant on npm. Most UNIX shells end with sh (bash, dash, ash, fish, zsh, ksh, csh, tcsh, etc.), so xsh can be a bit confusing.

Sounds great to me, @nfischer?

I prefer shx to xsh for the reasons @TimothyGu noted. I'd still prefer a 4-letter name that has "js" somewhere in there (xjsh and jshx are available options along those lines). If a 3-letter name is a priority, then I'd vote for shx.

Ok, shx it is.

I'll implement tomorrow, first thing in the AM.

Ari

On Sun, Jan 31, 2016 at 8:56 PM, Nate Fischer [email protected]
wrote:

I prefer shx to xsh for the reasons @TimothyGu
https://github.com/TimothyGu noted. I'd still prefer a 4-letter name
that has "js" somewhere in there (xjsh and jshx are available options
along those lines). If a 3-letter name is a priority, then I'd vote for
shx.

—
Reply to this email directly or view it on GitHub
#244 (comment).

SGTM

It looks like this is blocked by #269.

@ariporad you can set up the repo now and get the basic utility built. Then error codes can be added soon after

Ok everyone, initial implementation in shelljs/shx. Feedback welcome!

If people are satisfied with the extra repo, we can probably close this issue. Thoughts?

Seems to work really nice for me. Thank you very much for implementing this.

One little side discovery: will the shojis binary will go away then in the future? I think it might be misleading to have two.

@tobiastom: We don't have a shojis binary 😝, but as far as the shjs goes, I'm not sure... I don't really see a use for it. @nfischer?

Also, closing this.

For people who see this in the future, this has been moved to shelljs/shx#1. Please continue discussion there. (And I'm going to lock this thread).

@ariporad the shjs bin file is still useful. It executes shelljs scripts without the need for modifying NODE_PATH, which is convenient for some (I know I found it convenient before I realized I could modify that).