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

Bash prompts and single-word heading capitalization #106

Merged
merged 4 commits into from
Apr 20, 2016

Conversation

RichardLitt
Copy link
Member

@dignifiedquire
Copy link
Member

LGTM

@@ -5,6 +5,7 @@ This is the documentation styleguide for our natural language descriptions used
## Code references

* Use `backticks` for every code example inside of a normal description. In the CLI, where you cannot use backticks, use 'single quotes' for commands.
* For bash arguments, do not include a `$` before commands in man pages. A `$` may be included in READMEs.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "bash arguments" mean here? Perhaps "command line invocations"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not bash but rather shell as there are more shells than just bash ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shell makes sense. Does that satisfy you, @noffle?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm partial to command line, if only because I get the [subjective] impression more people know what it means than shell. Either works for me. 👍

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

('shell' includes graphical as well as voice input, e.g. https://www.emacswiki.org/emacs/EmacSpeak)

@RichardLitt RichardLitt force-pushed the feature/doc-fixes branch 2 times, most recently from b05c7a8 to 9b80855 Compare February 5, 2016 18:17
@rht
Copy link

rht commented Feb 6, 2016

Citation suggestion: much like how https://github.com/ipfs/community/blob/master/code-of-conduct.md attributes the npm code of conduct, I think this should be the case as well for docs-styleguide.md.
http://man7.org/linux/man-pages/man7/man-pages.7.html should be cited (better if there is an immutable link to this).

('@'related: if you want to see what precedes npm coc, and so on, here is an incomplete visualization of it http://ideapad.io/code-of-conduct-phylogenetic-tree/graph)

@daviddias
Copy link
Member

LGTM

@RichardLitt
Copy link
Member Author

@rht That makes sense to me. We can link that. Want to make a PR about it?

@dignifiedquire
Copy link
Member

Ping @whyrusleeping @rht @jbenet for review

@whyrusleeping
Copy link
Member

@jbenet is going to want > instead of $ i think, i saw him post about that recently

@RichardLitt
Copy link
Member Author

@whyrusleeping agreed. I'm not sure when to use that: everywhere?

I see two issues with this. One is that most beginners come from Mac environments, I would think, and would be used to $. The second is that I have often seen this notation:

$ run command
> this is the output

Where > is used to mean STDOUT. I wonder if > would lead people to wonder if it is STDOUT or the command.

@whyrusleeping
Copy link
Member

yeah, i'm personally not a fan of using > and prefer $. this PR has a LGTM from me

@dignifiedquire
Copy link
Member

I just checked man git-commit and it does

It is a rough equivalent for:

$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD

@RichardLitt RichardLitt removed dif/easy Someone with a little familiarity can pick up help wanted needs review labels Mar 9, 2016
@RichardLitt RichardLitt merged commit aab8094 into master Apr 20, 2016
@RichardLitt RichardLitt deleted the feature/doc-fixes branch April 20, 2016 19:54
@jbenet jbenet removed the status/in-progress In progress label Apr 20, 2016
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.

7 participants