Code Monkey home page Code Monkey logo

shdoc's Introduction

shdoc

shdoc is a documentation generator for bash/zsh/sh for generating API documentation in Markdown from shell scripts source.

shdoc parses annotations in the beginning of a given file and alongside function definitions, and creates a markdown file with ready to use documentation.

Index

Example

Generate documentation with the following command:

$ shdoc < lib.sh > doc.md

Source examples/readme-example.sh
Output: examples/readme-example.md

#!/bin/bash
# @file libexample
# @brief A library that solves some common problems.
# @description
#     The project solves lots of problems:
#      * a
#      * b
#      * c
#      * etc

# @description My super function.
# Not thread-safe.
#
# @example
#    echo "test: $(say-hello World)"
#
#
# @option -h | --help Display help.
# @option -v<value> | --value=<value> Set a value.
#
# @arg $1 string A value to print
#
# @stdout Output 'Hello $1'.
#   It hopes you say Hello back.
# @stderr Output 'Oups !' on error.
#   It did it again.
#
# @exitcode 0 If successful.
# @exitcode 1 If an empty string passed.
#
# @see validate()
# @see [shdoc](https://github.com/reconquest/shdoc).
say-hello() {
    if [[ ! "$1" ]]; then
        echo "Oups !" >&2
        return 1;
    fi

    echo "Hello $1"
}
# libexample

A library that solves some common problems.

## Overview

The project solves lots of problems:
* a
* b
* c
* etc

## Index

* [say-hello](#say-hello)

### say-hello

My super function.
Not thread-safe.

#### Example

```bash
echo "test: $(say-hello World)"
```

#### Options

* **-h** | **--help**

  Display help.

* **-v\<value\>** | **--value=\<value\>**

  Set a value.

#### Arguments

* **$1** (string): A value to print

#### Exit codes

* **0**: If successful.
* **1**: If an empty string passed.

#### Output on stdout

* Output 'Hello $1'.
  It hopes you say Hello back.

#### Output on stderr

* Output 'Oups !' on error.
  It did it again.

#### See also

* [validate()](#validate)
* [shdoc](https://github.com/reconquest/shdoc).

Features

@name

A name of the project, used as a title of the doc. Can be specified once in the beginning of the file.

Example

#!/bin/bash
# @name MyLibrary

@file

Identical to @name.

@brief

A brief line about the project. Can be specified once in the beginning of the file.

Example

#!/bin/bash
# @brief A library to solve a few problems.

@description

A multiline description of the project/section/function.

  • Can be specified once for the whole file in the beginning of the file.
  • Can be specified once for a section of the file. See @section.
  • Can be specified once for on top of a function definition.

Example

#!/bin/bash
# @description A long description of the library.
# Second line of the project description.

# @description My super function.
# Second line of my super function description.
function super() {
    ...
}

@section

The name of a section of the file. Can be used to group functions.

Example

# @section My utilities functions
# @description The following functions can be used to solve problems.

@example

A multiline example of the function usage. Can be specified only alongside the function definition.

Example

# @example
#    echo "test: $(say-hello World)"
say-hello() {
    ...
}

@option

A description of an option expected to be passed while calling the function. Can be specified multiple times to describe any number of arguments. If an option argument is expected, it must be specified between < and >

Example

# @description Says hi to a given person.
# @option -h A short option.
# @arg --value=<value> A long option with argument.
# @arg -v<value> | --value <value> A long option with short option alternative.
say-hello() {
    ...
}

@arg

A description of an argument expected to be passed while calling the function. Can be specified multiple times to describe any number of arguments.

Example

# @description Says hi to a given person.
# @arg $1 string A person's name.
# @arg $2 string Message priority.
say-hello() {
    ...
}

@noargs

A note that the function does not expect any arguments to be passed.

Example

# @description Says 'hello world'.
# @noargs
say-hello-world() {
    ...
}

@set

A description of a global variable that is set while calling the function. Can be specified multiple times to describe any number of variables

Example

# @description Sets hello to the variable REPLY
# @set REPLY string Greeting message.
set-hello() {
    ...
}

@exitcode

Describes an expected exitcode of the function. Can be specified multiple times to describe all possible exitcodes and their conditions.

Example

# @description Says 'hello world'.
# @exitcode 0 If successful.
# @exitcode 1 If world is gone.
say-hello-world() {
    ...
}

@stdin

The expected input to the function call from stdin (usually the terminal or command line)

Example

# @description Asks name.
# @stdin The users name from the terminal/command line.
say-hello-world() {
    ...
}

@stdout

An expected output of the function call.

Example

# @description Says 'hello world'.
# @stdout A path to a temporary file with the message.
say-hello-world() {
    ...
}

@stderr

An expected output of the function call on /dev/stderr.

Example

# @description Says 'hello world'.
# @stderr A error message when world is not available.
say-hello-world() {
    ...
}

@see

Create a link on the given function in the "See Also" section.

Example

# @see say-hello
# @see text with [markdown link](./other-file#other-function)
say-hello-world() {
    ...
}

@internal

When you want to skip documentation generation for a particular function, you can specify this @internal tag. It allows you to have the same style of doc comments across the script and keep internal functions hidden from users.

Example

# @internal
show-msg() {
    ...
}

Usage

shdoc has no args and expects a shell script with comments on stdin and will produce markdown as stdout.

$ shdoc < your-shell-script.sh > doc.md

Installation

Arch Linux

Arch Linux users can install shdoc using package in AUR: shdoc-git

Using Git

NOTE: shdoc requires gawk: apt-get install gawk

git clone --recursive https://github.com/reconquest/shdoc
cd shdoc
sudo make install

Others

Unfortunately, there are no packages of shdoc for other distros, but we're looking for contributions.

Examples

See example documentation on:

LICENSE

MIT

shdoc's People

Contributors

ariana-hlavaty-i2 avatar constrict0r avatar denkoren avatar hyperupcall avatar kovetskiy avatar landure avatar rbairwell avatar rockandska avatar seletskiy avatar tomjn avatar yanagiragi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

shdoc's Issues

Regarding hyperlink option non-availability

Hi Team,

Currently i am not able to find a way to create hyperlink in generated .md file. If opened in browser the generated .md file it is all plain .So do we have any option with which we can create hyperlink b/w Index and functions.
Do we have option to create pdf file documentation as well from shdoc itself as well?

Thanks

shdoc release

I'm working to package shdoc for Fedora and would like to check if you plan to do tradional (semver?) releases or create tags for shdoc or rather prefer to keep like now.

@description with indent does not work

First of all, thank you for this really useful application. That helps me to document my bash scripts with low effort.
Developing bash scripts with VSCodium and Bash IDE, I am used to indent the functions. That allows me the folding of source text. Using annotations like @example, @arg, @exitcode, and @see is no problem, they work fine with indentation. But when I indent the @description, it disappears. So please change the handling of @description, so that indentation is possible. Thanks.

Add an example of usage in the README

Can you please add an example/examples of how you call shdoc to the README?

shdoc.awk has no args and expects shell script with comments as described above on the stdin and will markdown output result on the stdout.

Seeing that it takes input via the STDIN with no arguments, I tried a few different things all of which did not work:

$ cat .bash_profile | shdoc
/usr/bin/awk: calling undefined function gensub
 input record number 5, file 
 source line number 47
$ shdoc .bash_profile     # I knew this one wouldn't work...
/usr/bin/awk: calling undefined function gensub
 input record number 5, file .bash_profile
 source line number 47
$ shdoc << .bash_profile
>                                             # I hit ^C to get out of this
$ shdoc <<< .bash_profile



# Empty space printed ^^^
$ $ shdoc <<< cat .bash_profile
/usr/bin/awk: calling undefined function gensub
 input record number 5, file .bash_profile
 source line number 47
$ shdoc <<< $(cat .bash_profile)


# Empty space printed ^^^

I'm not having any luck with trying things out / Googling for how to provide STDIN to a script. I'm no bash expert, but I'd love to use your project! So could you please provide some explicit calls you use to use shdoc?

Add support for sections in the doc

The ability to add sections to group together functions.

For example if a script looks like:

  # @section Section A
  # @description a
  # a
  
  # @description func a
  # line a 2
  a() {
  }
  
  # @section Section B
  # @description b
  
  # @description func b
  # ab
  b() {
  }

the generated md file would look like:

## Section A

a
a

### a

func a
line a 2

## Section B

b

### b

func b
ab

Question about the reason for @std{in,out,err} complexity

I'm preparing a PR for a feature I want to add (removing the space requirement between the # and the annotations).

In my local copy I've made the shdoc changes and I'm creating test cases for my "nospace" feature based on the current test cases.

The @std{in,out,err} tests are failing. When I went to look at the shdoc code to figure out why, I see a confusing situation for those annotations. Unlike the other multiline annotations (@description, @example), the @std{in,out,err} annotations have a large and complex set of code for the purpose of tracking indentation. But I can't figure out why--what is the use case for tracking indentation on a multiline @stderr block and not a multiline @example block, for example? Why can't a @stdout block be treated the same as a @description block?

[TOC] wrong with functions containing '-'

Hi,

I didn't test shdoc yet but it looks like exactly what I'm looking for ^^
From the demo, I observed that some anchor doesn't work. Its seems only hit functions containing '-'.

It is related to this part of code who seems a bit brutal πŸ˜„

shdoc/shdoc

Line 167 in e334b02

gsub(/\W/, "", url)

Regards

Double-digit argument lists are processed incorrectly

When I create a documentation block like this:

# @description This function has a lot of arguments.
#
# @arg $1 string Arg 1
# @arg $2 string Arg 2
# @arg $3 string Arg 3
# @arg $4 string Arg 4
# @arg $5 string Arg 5
# @arg $6 string Arg 6
# @arg $7 string Arg 7
# @arg $8 string Arg 8
# @arg $9 string Arg 9
# @arg $10 string Arg 10
my_function() {...}

The double-digit argument ($10) is not processed correctly. The output I get is:

### my_function()

This function has a lot of arguments.

#### Arguments

* **$1** (string): Arg 1
* **$2** (string): Arg 2
* **$3** (string): Arg 3
* **$4** (string): Arg 4
* **$5** (string): Arg 5
* **$6** (string): Arg 6
* **$7** (string): Arg 7
* **$8** (string): Arg 8
* **$9** (string): Arg 9
* $10 string Arg 10

Add support for optional arguments and/or getopt-style options

Great project! Thanks for all of your work on it πŸ™ŒπŸ»

Before I can convert my function docs to shdoc annotations, I need to find a way to mark arguments as optional, i.e. something equivalent to this:

# my_func REQUIRED_ARG [OPTIONAL_ARG]
my_func() {
  # ...
}

A few possibilities for the melting pot of ideas:

  1. @arg?
# @arg $1 string A required argument.
# @arg? $2 string An optional argument.
  1. @arg [$2]
# @arg $1 string A required argument.
# @arg [$2] string An optional argument.
  1. @arg ?$2
# @arg $1 string A required argument.
# @arg ?$2 string An optional argument.

Non-positional arguments a.k.a. getopt-style options

I don't have suggested syntax ready to go, but annotations to add support for getopt-style options (flags, values, optional values) would be excellent.

These are typically described as follows, where REQUIRED and OPTIONAL are positional:

# my_func [-f] [-w VALUE] [-wOPTIONAL_VALUE] REQUIRED [OPTIONAL...]

Caveats

More complex arrangements would probably be too difficult to design intuitive annotation syntax for and could be explained in @description if needed:

# my_func REQUIRED_ARG [[OPTIONAL_ARG2] OPTIONAL_ARG]

That said, maybe an optional @synopsis tag or similar could be used to provide a compact one-line summary using agreed syntax Γ  la docopt:

# @synopsis my_func <required_arg> [[optional_arg2] optional_arg]

A default synopsis could be generated from @arg annotations if not given explicitly.

Request to make @description optional as in JavaDoc

Just to be even easier to pick up after being proficient in JavaDoc (and all its siblings), I propose the @description tag to be dropped for functions, falling back to the assumption the first line of the header comment starts the description.

Indented function descriptions are not parsed

Given the following test file:

#!/usr/bin/env bash
# @file testdoc.sh
# @brief Demo
# @description Demonstration.

# @description Something
# something dark side.
#
# @example
#   testme()
#
# @noargs
testme() {
    echo "Hello"
}

if [[ 1 -eq 2 ]]; then

    # @description Another bit of
    # comment.
    #
    # @example
    #   testus()
    #
    # @noargs
    testus() {
        echo "Hello"
    }
fi

I would expect similar documentation output for both testme and testus - however, I get testus missing its description (but it does include the examples). I can't quite see why this is happening myself, but I'm not familiar with gawk.

Here is the output with debug mode enabled: using:

export SHDOC_DEBUG=1
shdoc testdoc.sh

DEBUG: line: [#!/usr/bin/env bash]
DEBUG: β†’ NOT HANDLED
DEBUG: line: [# @file testdoc.sh]
DEBUG: β†’ @name|@file
DEBUG: line: [# @brief Demo]
DEBUG: β†’ @brief
DEBUG: line: [# @description Demonstration.]
DEBUG: β†’ @description
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: β†’ β†’ in_description: concat
DEBUG: line: []
DEBUG: β†’ β†’ in_description: leave
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: added
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ reset()
DEBUG: line: [# @description Something]
DEBUG: β†’ @description
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: β†’ β†’ in_description: concat
DEBUG: line: [# something dark side.]
DEBUG: β†’ β†’ in_description: concat
DEBUG: line: [#]
DEBUG: β†’ β†’ in_description: concat
DEBUG: line: [# @example]
DEBUG: β†’ β†’ in_description: leave
DEBUG: β†’ handle_description
DEBUG: β†’ @example
DEBUG: line: [#   testme()]
DEBUG: β†’ β†’ in_example: concat
DEBUG: line: [#]
DEBUG: β†’ β†’ in_example: leave
DEBUG: β†’ NOT HANDLED
DEBUG: line: [# @noargs]
DEBUG: β†’ @noargs
DEBUG: line: [testme() {]
DEBUG: β†’ function
DEBUG: β†’ β†’ function: register
DEBUG: β†’ render_docblock
DEBUG: β†’ β†’ func_name: [testme]
DEBUG: β†’ β†’ description: [Something
something dark side.
]
DEBUG: β†’ reset()
DEBUG: line: [    echo "Hello"]
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: [}]
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: []
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: [if [[ 1 -eq 2 ]]; then]
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: []
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: [    # @description Another bit of]
DEBUG: β†’ @description
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: β†’ β†’ in_description: leave
DEBUG: β†’ handle_description
DEBUG: β†’ NOT HANDLED
DEBUG: line: [    # comment.]
DEBUG: β†’ NOT HANDLED
DEBUG: line: [    #]
DEBUG: β†’ NOT HANDLED
DEBUG: line: [    # @example]
DEBUG: β†’ @example
DEBUG: line: [    #   testus()]
DEBUG: β†’ β†’ in_example: concat
DEBUG: line: [    #]
DEBUG: β†’ β†’ in_example: leave
DEBUG: β†’ NOT HANDLED
DEBUG: line: [    # @noargs]
DEBUG: β†’ @noargs
DEBUG: line: [    testus() {]
DEBUG: β†’ function
DEBUG: β†’ β†’ function: register
DEBUG: β†’ render_docblock
DEBUG: β†’ β†’ func_name: [testus]
DEBUG: β†’ β†’ description: [
]
DEBUG: β†’ reset()
DEBUG: line: [        echo "Hello"]
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: [    }]
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: line: [fi]
DEBUG: β†’ break
DEBUG: β†’ handle_description
DEBUG: β†’ β†’ description: empty
DEBUG: β†’ reset()
DEBUG: β†’ END {
DEBUG: β†’ β†’ file_title:       [testdoc.sh]
DEBUG: β†’ β†’ file_brief:       [Demo]
DEBUG: β†’ β†’ file_description: [Demonstration.
]
DEBUG: β†’ END }
# testdoc.sh

Demo

## Overview

Demonstration.

## Index

* [testme](#testme)
* [testus](#testus)

### testme

Something
something dark side.

#### Example

'''bash
testme()
'''

_Function has no arguments._

### testus



#### Example

'''bash
testus()
'''

_Function has no arguments._

[note: I did change the backslashes in the outputted code samples to be single quote marks to avoid Github handling it as formatting]

Platform
Docker: debian:bullseye
GNU Awk version: 5.1.0 API: 3.0
shdoc commit version 433a0ba (6th April)

(And before anyone asks, no that is not real in use code, but I've just reduced it down to a test case - there is a reason I've got a function within an if statement and it is formatted by shfmt, checked by shellcheck and runs on in my Bash 5 environment - so I think it's valid code ;) )

( How did I miss #21 ? )

Feature Request: Documenting REPLY

I think it would be useful to be able to document what return variables like REPLY and REPLY1, REPLY1, etc. mean.

It could possibly look like the following

# @reply REPLY string The full path to your root project folder

Thoughts?

Bug: Functions with underscores in the name break index links

Function:

# @description Checks if all required environment variables are set.
# @noargs
function check_env_vars_are_set() {
   ...
}

Generated .md:

## Index

* [check_env_vars_are_set](#check_env_vars_are_set)

Expected .md:

## Index

* [check_env_vars_are_set](#checkenvvarsareset)

License request

Would it be possible to have a license attributed to this of some sort?

Thanks

It may be some problem of mine but I can't use the script. Any bash file that I pass as a parameter it returns me 3 empty lines.

Warning and error in doc generation when short"-" or long "--" are used in @arg

My functions use the long and short options format. For example:

#
# @arg -s/--sequence (optional) Show sequence.
# @arg -j/--jobs     (optional) Number of CPU cores to use.
#

When running shdoc over my scripts the following message appears:

line   44, warning : Invalid format: @arg -s/--sequence (optional) Show sequence.
line   45, warning : Invalid format: @arg -j/--jobs     (optional) Number of CPU cores to use.

And the generated .md output is incomplete and/or truncated.

ΒΏIs there a way to fix it? ΒΏSi something from my side?

wrong argument ordering and numbering when the number of argument >= 4

For the function block

  1. when you have 4 @arg or more, the generated markdown becomes unordered
  2. when you have 10 @arg or more, the generated markdown does no more apply the bold pattern

To correct this:

line 26,
replace: styles["github", "argN", "from"] = "^(\$[0-9]) (\S+)"
by: styles["github", "argN", "from"] = "^(\$[0-9]+) (\S+)"

line 203,
replace: for (i in docblock["arg"]) {
by: for (i =1; i <= length(docblock["arg"]); i++) {

Parse error of { on a separate line

This isn't parsed:

#!/sbin/sh

# @description My super function.
#
# @arg $1 string A value to print
say-hello()
{
    if [[ ! "$1" ]]; then
        return 1;
    fi

    echo "Hello $1"
}

It is sufficient to put { in the same line of say-hello() to make it working but I don't like it.
Can it be fixed please?

Proposal to go POSIX: gawk -> awk

Proposing not to depend on the GNU extensions, as many lightweight systems and their components (Alpine, BusyBox, ...) would not contain specific versions of GNU awk by default.

Add support for cross documentation @see links

The ability to cross reference with the @see annotation, a possible solution could be to provide the path to where the source functions md file is stored.

For example if

  • script1.sh has a function called my1stfunction() that uses my2ndfunction() from script2.sh

with the folder structure

.
β”œβ”€β”€ folder1
β”‚   β”œβ”€β”€ script1.md
β”‚   └── script1.sh
└── folder2
    β”œβ”€β”€ script2.md
    └── script2.sh

the generated md file would lok like

### my1stfunction

My 1st Function

_Function has no arguments._

#### Output on stdout

* None

#### See also

* [my2ndfunction)](/folder2/script2.md#my2ndfunction)
* [my2ndfunction)](../folder2/script2.md#my2ndfunction) (also works too)

A example of the annotation could be
# @see [/folder2/script2.md] my2ndfunction

Multiple input files to multiple output files with links ?

Hi,

I would like to know if you already used this tool to take multiple files (like a set of tools function files and a script) and generate the documentation for the whole.

Would it be possible to make links automatically between those files or is it mandatory to concat everything to one single file to a single MD file too?

I hope my question is quite understandable...

to illustrate a simple scenario :


MyLib.sh
MyScript.sh (in which there is a `. MyLib.sh`)

`shdoc MyLib.sh MyScript.sh`

=> Generates

- MyScript.md
- MyLib.md

If in 'MyScript.sh', there is a `@See MyLibFunction1` then, the is a link to a section in file 'MyLib.md'

Bug fix: allow white space in function decl

First, great library, very useful. Saved me a TON of work building the same :)

When trying to use it on our existing codebase I found a "bug" where if you use whitespace in your function decl's it throws things off due to the pattern you used (line 143/4 depending on your start preference):

/^(function )?([a-zA-Z0-9_:-]+)(\(\))? \{/ && docblock != "" {

Changing that to the following allows whitespace:

/^(function([ \t])+)?([a-zA-Z0-9_:-]+)([ \t]*)(\(([ \t]*)\))?([ \t]*)\{/ && docblock != "" {

compatablity ? and ?shdoc.md!

shdoc is a documentation generator for bash/zsh/sh for generating API documentation in Markdown from shell scripts source.

shdoc parses annotations in the beginning of a given file and alongside function definitions, and creates a markdown file with ready to use documentation.

give the above quote from readme.md it appears that any language supporting '# comment '
should work

unless some other reason exist making ssb exclusive to bash/zsh/sh?

... with the above in mind has any consideration been given to

  • documenting the shdoc awk script !
  • expanding the stated compatibility to "any language supporting '# comment ' " ?

Issue when no space between () and {

This got me looking for a solid 10 minutes.

# @brief This will show
# @description This will **not** show
gabr(){
 return 0
}

What fixed for me is:

# @brief This will show
# @description This will show
gabr() { # <- note the space here
 return 0
}

I don't have time to look for this issue right now, so dropping this here without PR

Documenting variables

Hi reconquest,

First of all, thanks for making such a great project, it's really good

I'd like to document some variables in a similar method as the functions, actually, only the description annotation would be good.

Please can you implement this?

For example:
You could describe a variable as # @description error color

for this variable:
_logging_color_error='\e[31m'; #red

and for result:

@description error color

_logging_color_error='\e[31m'; #red

Request support for `@deprecated`

I think it would be quite useful to have a @deprecated flag. Unlike @internal, I believe the documentation for the function should actually be generated, but show some notice somewhere that it is deprecated. More specifically, changing a function subheading in the markdown from ### core.init() to ### core.init() (deprecated) comes to mind, but perhaps another layout could look nicer.

Real-world uses of this functionality can be found here and here

Is there any interest in this? I'd be happy to make a PR for this :)

Update Installation Instructions

Update the clone line to read

git clone --recurse-submodules https://github.com/reconcquest/shdoc

If anyone wants complete instructions for Ubuntu they would be

sudo apt-get update
sudo apt-get install gawk
git clone --recurse-submodules https://github.com/reconcquest/shdoc
cd shdoc
sudo make install

Gawk version dependency

Is there a specific version of "gawk" that is required?

I have installed "gawk" into a Docker container image with the "shdoc" included, but it is not generating correctly.

  • Correctly generates the markdown for the script header (the @file, @brief and @description)
  • Does not generate any content for functions (for my own, and even for your demo script)

The full output with your example script is:

# libexample

A library that solves some common problems.

## Overview

The project solves lots of problems:
* a
* b
* c
* etc



feature request: Add support for @stderr

It is not rare for script to output debug info or error message on &2 (stderr). It would be nice if shdoc supported this functionnality.

Thank you for your work.

"####" output in Exit codes or Arguments

When I document my functions the output generated will have #### output after Exit code print or in Arguments.

For eg:

Exit codes

     * 0: Success #### Output on stdout

See also section is missing a trailing newline

I'm seeing this:

#### See also

* [vvv_get_site_config_value](#vvvgetsiteconfigvalue)
### get_hosts()

But expecting this:

#### See also

* [vvv_get_site_config_value](#vvvgetsiteconfigvalue)

### get_hosts()

Function output

Could you add a description section for @returns, so that it is possible to document what is returned from the function?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.