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

Use sh instead of bash for shell code snippets #136

Closed
wants to merge 1 commit into from

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Aug 24, 2020

@aduh95 aduh95 changed the title Use sh instead of bash for shell code sample Use sh instead of bash for shell code snippets Aug 24, 2020
index.js Outdated Show resolved Hide resolved
@nschonni
Copy link
Member

@Trott does this need to be done in 2 phases? EX: one to add the new language, release, then a second one to turn off bash?

@DerekNonGeneric
Copy link
Contributor

We don't want sh on purpose! Look at the reason why. It's confusing.

https://twitter.com/BrendanEich/status/1278803332287483904

@aduh95
Copy link
Contributor Author

aduh95 commented Aug 25, 2020

@DerekNonGeneric could you elaborate on what is the confusion? The tweet you referenced in the previous comment seems to be about how to name JavaScript/JS, but the discussion here is about replacing bash (Bourne Again Shell) with sh (Shell Command Language described by the POSIX standard).

Using bash in Node.js docs always seemed weird to me (I'm a fish and zsh user). Please see this StackOverflow answer for more context:

I prefer sh [over bash] for the following reasons:

  • it is standardized
  • it is portable across POSIX systems — even if they happen not to have bash, they are required to have sh

@Trott
Copy link
Member

Trott commented Aug 26, 2020

@Trott does this need to be done in 2 phases? EX: one to add the new language, release, then a second one to turn off bash?

Probably. Another option is to do phase 1 only or at least allow that phase 1 will be very long.

I'm conflicted and ultimately neutral on this change. I'm fine with bash being what we use although I agree that sh is better semantics. The question is whether those improved semantics are worth all the churn and headache of changing. End users won't see any difference whatsoever. This is entirely for people writing/editing our documentation. Is the hassle of changing worth it? I certainly have a semantic purist streak that wants to see this happen, but pragmatically, I suspect it doesn't ultimately matter. But if someone is willing to do all the work, I won't stop them!

@aduh95
Copy link
Contributor Author

aduh95 commented Oct 12, 2020

Can this get merge please?

@DerekNonGeneric
Copy link
Contributor

Can this get merge please?

It's not a good idea though, I don't see why you would prefer a more ambiguous info string.

@aduh95
Copy link
Contributor Author

aduh95 commented Oct 12, 2020

It's not a good idea though, I don't see why you would prefer a more ambiguous info string.

Are you saying bash less ambiguous than sh? To me they're just two names, I wouldn't say one is more confusing than the other. I can see you linked to a tweet, but it's a discussion about naming JS language, not a shell, so maybe you meant something else.

I don't want to go too deep into the bash bashing (pun intended), but there are good reasons we should use sh instead and I think they've already been outlined in this thread and the PR on node repo.

@DerekNonGeneric
Copy link
Contributor

DerekNonGeneric commented Oct 12, 2020

The point of linking to that tweet was that it's usually better to use the less-confusing (more clear, less likely to be confused) wording. They are also both scripting languages.

Would you mind briefly summarizing the case you are making for advocating for sh?

@zackschuster
Copy link

that tweet is about mixing up incompatible languages based on a short-sighted marketing decision from ~25 years ago; bash is explicitly, by-specification compatible with sh, so it's equivalent to switching from a concrete type to an interface.

@Trott
Copy link
Member

Trott commented Oct 13, 2020

I'm starting to wonder if it's not worth it to spend energy trying to identify the ideal choice here and we should allow both options. Heck, maybe allow shell as well (if it works with our toolchain). It also renders identically (at least in GFM, not sure about highlight.js).

@aduh95
Copy link
Contributor Author

aduh95 commented Oct 13, 2020

shell would be great, but it's unfortunately an alias to console in highlight.js.

Since @DerekNonGeneric has concerns that hasn't been addressed, I think we should indeed drop it. After all, as @Trott said in an earlier comment, this has no incidence at all on the HTML version of the docs.

@zackschuster
Copy link

i feel like the "ideal choice" is pretty cut-and-dry — it's part of a specification integral to node itself — and those concerns aren't relevant for reasons stated above. to be frank, i'm confused why there's even a debate. but i do agree this is an exceedingly minor change not worth exhausting oneself over, and if consensus is to drop it then i won't make a fuss 😄

@Trott
Copy link
Member

Trott commented May 29, 2021

I'm going to close this but feel free to reopen or comment if you feel like more conversation/effort/whatever is warranted.

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

Successfully merging this pull request may close these issues.

5 participants