Shell Documentation

Important

Keep in mind that this small project is intrinsically a constant WIP since I use it as my own form of documentation. As I learn more, I will keep this repository updated with new content.

Description

The following project is personal documentation for Shell basics and Shell scripting; at the current time, it includes BASH, and POWERSHELL. It is meant to be both as descriptive and as simple as possible to help in remembering the various elements touched on in this short, simplified manual. I maintain this project for two main reasons: firstly, i use it to train to write documentation; secondly, like they say, the best way to learn, is to explain, so this is exacly what i am doing (: .

Guidelines

As I mentioned, this project can be thorough, but it prioritizes intelligibility. Therefore, some aspects may be given less attention in favor of other descriptive points, such as the exact syntax. For example i won't detail all of the flags used for the described commands. View this manual as a simplified, more beginner-friendly version of original IEEE/POSIX/UNIX documentation you may usually find on the web.

Note

Still, if you wish for a more extensive coverage of the talked about themes, nothing is better than the standard UNIX user manual, to access it (for BASH and linux Shells), simply type man cmd where cmd is the command of which you want to learn the function, syntax, and much more (Works as well with standard C library functions). POWERSHELL uses the equivalent, updatable Get-Help cmdlet, as well as another simpler Get-Command cmdlet.

Caption and format

To avoid confusion when explaining any aspect, i made all my explanations respect a few formatting conventions.

• Listed elements like this sentence are the main points of information.

• Whenever a command's or a keyword's syntax is talked about, it adhers to it's own format: keyword arguments/targets , the main, often eponymous (giving it's name to the whole command) element of syntax will be in bold, while any placeholder name will be in italics to signify it depends on user input, is an argument, or is dependant on the main keyword in any way.

• Footnoted elements generally won't be explained in any more detail than they already have been, but will sometimes feature links to the relevant subject. View them as an invitation to do your own research, it is what we call in the universe of debating and talks "tendre une perche".¹

Contributing

If you'd like to contribute to this project, please follow these guidelines:

1. Fork the repository.
2. Create a new branch for your content.
3. Make your changes and commit them.
4. Push your changes to your fork.
5. Submit a pull request.

Footnotes

1. this note won't go into much detail to not overburden the explanation, it's just here to give you a lead. ↩