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

issue shell block quote is not always directly about formatting shell scripts #161

Open
ccoVeille opened this issue Apr 2, 2024 · 3 comments

Comments

@ccoVeille
Copy link
Contributor

shfmt is made for formatting script, definitely.

```shell
#!/bin/env bash

    date
```

But shell block quote in markdown is not ONLY about that

Yes, this would be valid

```shell
  cp   foo    bar
  touch   foo
```

But the alternative syntax used in many markdown linters is this one

$ command
result

So this

```shell
$ date
Tue Apr  2 23:54:37 CEST 2024
```

Please note this one is sometimes refered as console

```console
$ date
Tue Apr  2 23:54:37 CEST 2024
```
```console
foo@bar:~$ whoami
foo
```

So your script will try to format things that are not always script.

@ccoVeille
Copy link
Contributor Author

I'm not sure about the consequences of the things I'm raising, but at least now you know they exist

@hougesen
Copy link
Owner

hougesen commented Apr 2, 2024

Hmm, as far as I can tell shfmt doesn't have any issues formatting lines starting with $ (But it can't parse mdsf format <PATH_TO_FILE> which is rather ironic).

     $  cp   foo    bar
        $     touch    foo
$ date
Tue Apr  2 23:54:37 CEST 2024

Becomes

$ cp foo bar
$ touch foo
$ date
Tue Apr 2 23:54:37 CEST 2024

From a ux perspective I would personally expect any block tagged with shell / sh to be formatted using the shell formatter, whether it has a shebang or not. But I can definitely see your point.

I am honestly not sure what makes most sense 😅

@ccoVeille
Copy link
Contributor Author

Yes, exactly. My idea was for your to have this in your mind. Maybe add a test or twos.

So you can see how things evolve.

Because developing is east, maintaining is hard. So having unit tests is always better.

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

No branches or pull requests

2 participants