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

Get color code just will use for echoed recipe commands? #1702

Open
laniakea64 opened this issue Oct 16, 2023 · 4 comments
Open

Get color code just will use for echoed recipe commands? #1702

laniakea64 opened this issue Oct 16, 2023 · 4 comments

Comments

@laniakea64
Copy link
Contributor

Sometimes in shebang recipes it is useful to be able to echo some individual commands before running, the same as just echoes commands during a non-shebang recipe. Prior to #1670 , simply using bold color when echoing those commands would do the job. Now, it's no longer known in advance how echoed commands would look.

Could a just function to help this please be added?

Perhaps it could wrap a string in color codes same as just would wrap an echoed recipe line? Or, alternatively, perhaps it could take no arguments and return the color code just would use for echoing recipe lines?

Thanks 🙂

@sgtsquiggs
Copy link

sgtsquiggs commented Nov 10, 2024

+1 - I am finding myself using bash scripts more and more in justfiles - I'd like to have a way to echo commands and match just. Currently I have a just echo recipe that just assumes that the command is bold:

[private]
echo $text:
    #!/usr/bin/env bash
    bold=$(tput bold)
    normal=$(tput sgr0)
    echo "${bold}$text${normal}"

@casey
Copy link
Owner

casey commented Nov 10, 2024

We could expose color codes as constants, like we do with HEX and friends. So you could do:

foo:
  echo {{GREEN}}whatever{{NORMAL}}
```

Colors could be exposed both by their color name, like `GREEN`, and by their role in just's color formatting, like `ERROR`. Constants cannot be removed after they are added, so the names would need careful thought.

@laniakea64
Copy link
Contributor Author

We could expose color codes as constants,

(Tag #1645 )

Colors could be exposed both by their color name, like GREEN, and by their role in just's color formatting, like ERROR.

Interesting idea. This looks easier to use than a function.

Would it be problematic that constants would contain the raw \x1B character, which may need to be escaped where it's used?

Although if the raw \x1B character does works fine in most cases, there is replace(GREEN, "\u{1B}", '\x1B') for the times when it'd be an issue, which would also ensure the correct escape sequence for whatever specific context 🤔

@casey
Copy link
Owner

casey commented Nov 11, 2024

I just did a little testing, and they do need to be quoted, but not escaped, since the shell interprets both [ and ; as special characters.

So you need to do:

foo:
  echo 'foo {{CYAN}}bar{{NORMAL}} baz'

There are also other useful escape sequences, like clearing the screen, bold text, and cursor manipulation. Foreground and background can also be manipulated independently.

There are a few different kinds of color codes. There are eight standard colors (red, green, black, etc), eight high-intensity colors, 216 colors in a sort of color cube, 24 grayscale colors in steps, and 24-bit colors, which are arbitrary RGB values.

Maybe we should have constants for the eight standard colors, as well as things like bold, normal style, and clear screen, and a function which can be used for constructing arbitrarily complex escape sequences.

So this:

style('bold', 'fg:red', 'bg:#00f')

Would produce the escape sequence:

\x1b[1;31;48;2;0;0;255m

This is bold (1), red foreground color (31), blue background color as 24-bit color (48 is set background color, 2 introduces a 24-bit RGB color code with arguments 0, 0, and 255).

In addition to the standard color codes, a few more "semantic" color codes, which match just would be useful. These would match common colors used in just output. WARNING and ERROR, which are bold yellow and red respectively.

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

3 participants