Add cat to replace bat

[castrojo]

Recommendation via mastodon from dperson. However I'd like to turn off the line numbers so that multi line copy and paste works ootb. It's already in wolfi.

@jorge @UniversalBlue There's a --style option that takes the following arguments: default, full, auto, plain, changes, header, header-filename, header-filesize, grid, rule, numbers, snip.

Just checked and plain has no headers or line numbers. Still has pretty syntax highlighting. You can turn off pagination with --paging=never if you want to make it further emulate cat.

[bitsByB]

Hi @castrojo, would like to make first contribution but don't know what to do with this one.
Where/how can I find the link to what you guys are talking about?
I'd love a bit of guidance for the first one :) thanks

[m2Giles]

1. You will need to add bat to the installed packages file.

2. You will then need to set an alias for bat to cat with the associated flags listed above. We've been setting things for bash in a file inside /etc/profile.d/

3. Test to make sure it's behaving as expected.

4. Profit!

[bitsByB]

hey @m2Giles, thanks a lot for taking the time to answer !
I feel silly to ask those questions but I saw this issue was a good first issue so here I am.
Ok so let me try to make sense of it out loud:

• you're talking about doing all those things by downloading some repository on my computer, find the installed packages file and do the necessary changes, test it then submit the pull request right?
• Am I supposed to do that in a special environment?

I know you already broke it down for me but I would greatly appreciate if you could give me an even more detailed road map 😃
thanks

[m2Giles]

Yepp. Git clone the repo. Make the changes and the build the container using buildah. Test the container and if everything is good submit a pull request.

[bitsByB]

Thanks @m2Giles. Alright, so I think I have the 2 first steps ready:

1. You will need to add bat to the installed packages file.

I added the line bat in the packages.bluefin-cli

2. You will then need to set an alias for bat to cat with the associated flags listed above. We've been setting things for bash in a file inside /etc/profile.d/

I added

# Bat for cat
alias cat='bat --style=plain' 2>/dev/null

in modern-unix.sh

build the container using buildah. Test the container and if everything is good submit a pull request.

Now I'm not sure how to build the container using buildah.
I see I have it install on bluefin and I have the local repo toolboxes.
I've been looking at this tutorial (and a bunch of other docs) to find a way to build a container from a repo: https://github.com/containers/buildah/blob/main/docs/tutorials/02-registries-repositories.md with no success so far.

I would appreciate any hint (link, advice...) to finish this. thanks

[michaelhaaf]

@bitsByB I'm not a maintainer here, stumbled on this looking for something else, but I think I can help with one or two things.

I am very likely overexplaining some parts. I assume it's more helpful to risk overexplaination than assume "common" knowledge -- feel free to skim things you already know.

1. Tips for building a project using tools you're not familiar with

There's a billion tools for turning source code into executable software (that's "building") and the fact is there's no general recipe that works for every project.

When you aren't able to figure out how to do things from available documentation, it's always nice if you can a successful example and reverse engineer it from there.

Happily, we can find such an example in this repository. This project has public CI/CD (continuous integration/continuous deployment), i.e., the ability to write recipes ("workflows") for automated building and distribution of the software.

In general for projects using CI/CD on GitHub, you can find "workflow" files in the Actions tab of the GitHub repo page, or in the .github/workflow/ directory of the git repository itself. Somewhere in the workflow of this repository is the command for building these toolboxes.

Here comes the reverse-engineering: the workflow we're looking at is ultimately translated to a set of commands run in a Linux environment that you could replicate on your own Linux desktop; however, you can't just copy-paste this workflow file into your terminal. It doesn't hurt to make yourself familiar with the GitHub Action Workflow syntax if you're confused about any of the components of this file.

Here we can see some useful elements: the action used to build images is redhat-actions/buildah-build (you can look that up, but for now let's just say it's buildah build wrapped in a GitHub Action), the toolbox to be built is specified by a ContainerFile, e.g. ./toolboxes/bluefin-cli/Containerfile.bluefin-cli. There are extra arguments in the workflow that you shouldn't yourself need, i.e. the tags/registry/etc. which are the "distribution" part of the CI/CD (and you are currently just concerned with the "integration" part, i.e. the building).

Maybe this is enough to go on? You can try buildah build help on your terminal since I believe you have buildah already installed. If not, you can at least now search the documentation/google/etc. with a bit more knowledge of what the end goal should look like.

2. Notes about the git/GitHub workflow for contributing to open source projects

What I'm about to say is sort-of "cutting a corner" and you should be mindful about not taking people's time for granted (i.e. not spamming), but: there's often nothing wrong with submitting a draft pull-request with your changes before/in-parallel with testing/building the project yourself. The pull-request should not be accepted before you can demonstrate that the project builds, but you can get more direct feedback about the changes this way, and attempt builds as you go.

The workflow for doing that usually looks like:

• Make your own branch from the tip of main of the repo you plan to contribute to; or, make a fork of the repo you plan to contribute to and put your changes there instead. Either way: draft changes don't belong on the main branch of a shared repo -- the separate branch/fork allows developers to push changes freely without ruining the main branch state.
  • In general, since the branch policies of different projects vary, I almost always make forks of the projects I plan to contribute to.
  • If you change your mind about branch vs fork, you can always transfer your changes over (i.e. you're not Stuck with one choice or the other, so don't let choices like this paralyze you from getting started)
• commit your changes. If you made a fork, that can be on main or any other branch; if not, use your branch you created in the first step.
• Push your changes: if done right, you should be able to see your branch/fork as an option when you click "Pull Requests" -> "New Pull request". If you made a fork, you might have to click on a hyperlink saying "compare across forks".
• Describe the changes, what you've done, mark the pull request as draft.

TLDR, since I got a bit carried away: It's cool to learn by picking up good-first-issues, but depending on what you already know/don't know, the learning curve even for simple code changes can be steep! I would strongly recommend, at the same time as working on this issue, finding a good git/GitHub tutorial with examples and following along. https://git-scm.com/docs/user-manual is a great place to start; maybe there is a nice Youtube channel/playlist of someone working alongside the examples for reference.

[bitsByB]

wao! Thank you so much @michaelhaaf for this in depth explanation! that is really great 🙏
I'll look into it in more depth this weekend when I have more time.
And yes I learned the mechanics of git/github so that part should be fine 🙂
I really appreciate you taking the time! Take care Michael