dotfiles/grub-themes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Full rewrite

Browse source
This commit is contained in:
Matthias Morin 2021-03-08 18:13:24 +01:00
parent cafcc389ce
commit 81cee16d76
15 changed files with 1233 additions and 131 deletions
Download patch file Download diff file Expand all files Collapse all files

2
.gitattributes vendored
View file

@ -1,2 +0,0 @@
# Auto detect text files and perform LF normalization
* text=auto

33
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View file

@ -0,0 +1,33 @@
---
name: Bug report
about: Create a report to help us improve
title: ''
labels: ''
assignees: ''
---
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Call script with parameters ...
2. Type ...
3. Wait for ... seconds
4. See error
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots**
If applicable, add screenshots to help explain your problem.
**Desktop (please complete the following information):**
- OS: [e.g. MacOS]
- make version (make --version)
- Script version
- copy/paste output
**Additional context**
Add any other context about the problem here.

20
.github/ISSUE_TEMPLATE/feature_request.md vendored Normal file
View file

@ -0,0 +1,20 @@
---
name: Feature request
about: Suggest an idea for this project
title: ''
labels: ''
assignees: ''
---
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context or screenshots about the feature request here.

33
.github/workflows/bash_unit.yml vendored Normal file
View file

@ -0,0 +1,33 @@
name: bash_unit CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
ubuntu:
runs-on: ubuntu-latest
if: "! contains(toJSON(github.event.commits.*.message), '[skip ci]')"
steps:
- uses: actions/checkout@v2
- name: install Ubuntu dependencies with sudo apt install -y
run: sudo apt install -y gawk
- name: Unit testing with bash_unit
run: ./run_tests.sh
macos:
runs-on: macos-latest
if: "! contains(toJSON(github.event.commits.*.message), '[skip ci]') && contains(toJSON(github.event.commits.*.message), '[macos]')"
steps:
- uses: actions/checkout@v2
- name: install MacOS dependencies with brew install
run: brew install gawk
- name: Unit testing with bash_unit
run: ./run_tests.sh

17
.github/workflows/shellcheck.yml vendored Normal file
View file

@ -0,0 +1,17 @@
name: Shellcheck CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
shellcheck:
runs-on: ubuntu-latest
if: "! contains(toJSON(github.event.commits.*.message), '[skip ci]')"
steps:
- uses: actions/checkout@v2
- name: Check for code quality errors
run: ./run_linter.sh

29
CHANGELOG.md Normal file
View file

@ -0,0 +1,29 @@
Change Log
==========
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](http://keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).
## [Unreleased]
- WIP
## [1.0.0](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/releases/tag/1.0.0)
### Added
- .github/ISSU_TEMPLATE/bug_report.md
- .github/ISSU_TEMPLATE/feature_request.md
- .github/workflows/bash_unit.yml
- .github/workflows/shellcheck.yml
- CHANGELOG.md
- CODE_OF_CONDUCT.md
- CONTRIBUTING.md
- LICENSE
- run_linter.sh
- run_tests.sh
- unit tests
### Modified
- install.sh
- README.md

76
CODE_OF_CONDUCT.md Normal file
View file

@ -0,0 +1,76 @@
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at contact@christitus.com. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
https://www.contributor-covenant.org/faq

242
CONTRIBUTING.md Normal file
View file

@ -0,0 +1,242 @@
# Contributing
## How do I... <a name="toc"></a>
* [Use This Guide](#introduction)?
* Ask or Say Something? 🤔🐛😱
* [Request Support](#request-support)
* [Report an Error or Bug](#report-an-error-or-bug)
* [Request a Feature](#request-a-feature)
* Make Something? 🤓👩🏽‍💻📜🍳
* [Project Setup](#project-setup)
* [Contribute Documentation](#contribute-documentation)
* [Contribute Code](#contribute-code)
* Manage Something ✅🙆🏼💃👔
* [Provide Support on Issues](#provide-support-on-issues)
* [Label Issues](#label-issues)
* [Clean Up Issues and PRs](#clean-up-issues-and-prs)
* [Review Pull Requests](#review-pull-requests)
* [Merge Pull Requests](#merge-pull-requests)
* [Tag a Release](#tag-a-release)
* [Join the Project Team](#join-the-project-team)
* Add a Guide Like This One [To My Project](#attribution)? 🤖😻👻
## Introduction
Thank you so much for your interest in contributing!. All types of contributions are encouraged and valued. See the [table of contents](#toc) for different ways to help and details about how this project handles them!📝
Please make sure to read the relevant section before making your contribution! It will make it a lot easier for us maintainers to make the most of it and smooth out the experience for all involved. 💚
## Request Support
If you have a question about this project, how to use it, or just need clarification about something:
* Open an Issue at https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/issues
* Provide as much context as you can about what you're running into.
* Provide project and platform versions (bash, basher, etc), depending on what seems relevant. If not, please be ready to provide that information if maintainers ask for it.
Once it's filed:
* The project team will [label the issue](#label-issues).
* Someone will try to have a response soon.
* If you or the maintainers don't respond to an issue for 30 days, the [issue will be closed](#clean-up-issues-and-prs).
If you want to come back to it, reply (once, please), and we'll reopen the existing issue. Please avoid filing new issues as extensions of one you already made.
## Report an Error or Bug
If you run into an error or bug with the project:
* Open an Issue at https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/issues
* Include *reproduction steps* that someone else can follow to recreate the bug or error on their own.
* Provide project and platform versions (OS, bash, basher, etc), depending on what seems relevant. If not, please be ready to provide that information if maintainers ask for it.
Once it's filed:
* The project team will [label the issue](#label-issues).
* A team member will try to reproduce the issue with your provided steps. If there are no repro steps or no obvious way to reproduce the issue, the team will ask you for those steps and mark the issue as `needs-repro`. Bugs with the `needs-repro` tag will not be addressed until they are reproduced.
* If the team is able to reproduce the issue, it will be marked `needs-fix`, as well as possibly other tags (such as `critical`), and the issue will be left to be [implemented by someone](#contribute-code).
* If you or the maintainers don't respond to an issue for 30 days, the [issue will be closed](#clean-up-issues-and-prs). If you want to come back to it, reply (once, please), and we'll reopen the existing issue. Please avoid filing new issues as extensions of one you already made.
* `critical` issues may be left open, depending on perceived immediacy and severity, even past the 30 day deadline.
## Request a Feature
If the project doesn't do something you need or want it to do:
* Open an Issue at https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/issues
* Provide as much context as you can about what you're running into.
* Please be clear about why existing features and alternatives would not work for you.
Once it's filed:
* The project team will [label the issue](#label-issues).
* The project team will evaluate the feature request, possibly asking you more questions to understand its purpose and any relevant requirements. If the issue is closed, the team will convey their reasoning and suggest an alternative path forward.
* If the feature request is accepted, it will be marked for implementation with `feature-accepted`, which can then be done by either by a core team member or by anyone in the community who wants to [contribute code](#contribute-code).
Note: The team is unlikely to be able to accept every single feature request that is filed. Please understand if they need to say no.
## Project Setup
So you want to contribute some code! That's great! This project uses GitHub Pull Requests to manage contributions, so [read up on how to fork a GitHub project and file a PR](https://guides.github.com/activities/forking) if you've never done it before.
If this seems like a lot or you aren't able to do all this setup, you might also be able to [edit the files directly](https://help.github.com/articles/editing-files-in-another-user-s-repository/) without having to do any of this setup. Yes, [even code](#contribute-code).
If you want to go the usual route and run the project locally, though:
* [Fork the project](https://guides.github.com/activities/forking/#fork)
Then in your terminal:
* `cd path/to/your/clone`
And you should be ready to go!
## Contribute Documentation
Documentation is a super important, critical part of this project. Docs are how we keep track of what we're doing, how, and why. It's how we stay on the same page about our policies. And it's how we tell others everything they need in order to be able to use this project -- or contribute to it. So thank you in advance.
Documentation contributions of any size are welcome! Feel free to file a PR even if you're just rewording a sentence to be more clear, or fixing a spelling mistake!
To contribute documentation:
* [Set up the project](#project-setup).
* Edit or add any relevant documentation.
* Make sure your changes are formatted correctly and consistently with the rest of the documentation.
* Re-read what you wrote, and run a spellchecker on it to make sure you didn't miss anything.
* Write clear, concise commit message(s) using [conventional-changelog format](https://github.com/conventional-changelog/conventional-changelog-angular/blob/master/convention.md). Documentation commits should use `docs(<component>): <message>`.
* Go to https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/pulls and open a new pull request with your changes.
* If your PR is connected to an open issue, add a line in your PR's description that says `Fixes: #123`, where `#123` is the number of the issue you're fixing.
Once you've filed the PR:
* One or more maintainers will use GitHub's review feature to review your PR.
* If the maintainer asks for any changes, edit your changes, push, and ask for another review.
* If the maintainer decides to pass on your PR, they will thank you for the contribution and explain why they won't be accepting the changes. That's ok! We still really appreciate you taking the time to do it, and we don't take that lightly. 💚
* If your PR gets accepted, it will be marked as such, and merged into the `latest` branch soon after. Your contribution will be distributed to the masses next time the maintainers [tag a release](#tag-a-release)
## Contribute Code
We like code commits a lot! They're super handy, and they keep the project going and doing the work it needs to do to be useful to others.
Code contributions of just about any size are acceptable!
The main difference between code contributions and documentation contributions is that contributing code requires inclusion of relevant tests for the code being added or changed. Contributions without accompanying tests will be held off until a test is added, unless the maintainers consider the specific tests to be either impossible, or way too much of a burden for such a contribution.
To contribute code:
* [Set up the project](#project-setup).
* Make any necessary changes to the source code.
* Include any [additional documentation](#contribute-documentation) the changes might need.
* Write tests that verify that your contribution works as expected.
* Write clear, concise commit message(s) using [conventional-changelog format](https://github.com/conventional-changelog/conventional-changelog-angular/blob/master/convention.md).
* Dependency updates, additions, or removals must be in individual commits, and the message must use the format: `<prefix>(deps): PKG@VERSION`, where `<prefix>` is any of the usual `conventional-changelog` prefixes, at your discretion.
* Go to https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/pulls and open a new pull request with your changes.
* If your PR is connected to an open issue, add a line in your PR's description that says `Fixes: #123`, where `#123` is the number of the issue you're fixing.
Once you've filed the PR:
* Barring special circumstances, maintainers will not review PRs until all checks pass (Travis, AppVeyor, etc).
* One or more maintainers will use GitHub's review feature to review your PR.
* If the maintainer asks for any changes, edit your changes, push, and ask for another review. Additional tags (such as `needs-tests`) will be added depending on the review.
* If the maintainer decides to pass on your PR, they will thank you for the contribution and explain why they won't be accepting the changes. That's ok! We still really appreciate you taking the time to do it, and we don't take that lightly. 💚
* If your PR gets accepted, it will be marked as such, and merged into the `latest` branch soon after. Your contribution will be distributed to the masses next time the maintainers [tag a release](#tag-a-release)
## Provide Support on Issues
Helping out other users with their questions is a really awesome way of contributing to any community. It's not uncommon for most of the issues on an open source projects being support-related questions by users trying to understand something they ran into, or find their way around a known bug.
Sometimes, the `support` label will be added to things that turn out to actually be other things, like bugs or feature requests. In that case, suss out the details with the person who filed the original issue, add a comment explaining what the bug is, and change the label from `support` to `bug` or `feature`. If you can't do this yourself, @mention a maintainer so they can do it.
In order to help other folks out with their questions:
* Go to the issue tracker and [filter open issues by the `support` label](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/issues?q=is%3Aopen+is%3Aissue+label%3Asupport).
* Read through the list until you find something that you're familiar enough with to give an answer to.
* Respond to the issue with whatever details are needed to clarify the question, or get more details about what's going on.
* Once the discussion wraps up and things are clarified, either close the issue, or ask the original issue filer (or a maintainer) to close it for you.
Some notes on picking up support issues:
* Avoid responding to issues you don't know you can answer accurately.
* As much as possible, try to refer to past issues with accepted answers. Link to them from your replies with the `#123` format.
* Be kind and patient with users -- often, folks who have run into confusing things might be upset or impatient. This is ok. Try to understand where they're coming from, and if you're too uncomfortable with the tone, feel free to stay away or withdraw from the issue. (note: if the user is outright hostile or is violating the CoC, [refer to the Code of Conduct](CODE_OF_CONDUCT.md) to resolve the conflict).
## Label Issues
One of the most important tasks in handling issues is labeling them usefully and accurately. All other tasks involving issues ultimately rely on the issue being classified in such a way that relevant parties looking to do their own tasks can find them quickly and easily.
In order to label issues, [open up the list of unlabeled issues](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) and, **from newest to oldest**, read through each one and apply issue labels according to the table below. If you're unsure about what label to apply, skip the issue and try the next one: don't feel obligated to label each and every issue yourself!
Label | Apply When | Notes
--- | --- | ---
`bug` | Cases where the code (or documentation) is behaving in a way it wasn't intended to. | If something is happening that surprises the *user* but does not go against the way the code is designed, it should use the `enhancement` label.
`critical` | Added to `bug` issues if the problem described makes the code completely unusable in a common situation. |
`documentation` | Added to issues or pull requests that affect any of the documentation for the project. | Can be combined with other labels, such as `bug` or `enhancement`.
`duplicate` | Added to issues or PRs that refer to the exact same issue as another one that's been previously labeled. | Duplicate issues should be marked and closed right away, with a message referencing the issue it's a duplicate of (with `#123`)
`enhancement` | Added to [feature requests](#request-a-feature), PRs, or documentation issues that are purely additive: the code or docs currently work as expected, but a change is being requested or suggested. |
`help wanted` | Applied by [Committers](#join-the-project-team) to issues and PRs that they would like to get outside help for. Generally, this means it's lower priority for the maintainer team to itself implement, but that the community is encouraged to pick up if they so desire | Never applied on first-pass labeling.
`in-progress` | Applied by [Committers](#join-the-project-team) to PRs that are pending some work before they're ready for review. | The original PR submitter should @mention the team member that applied the label once the PR is complete.
`performance` | This issue or PR is directly related to improving performance. |
`refactor` | Added to issues or PRs that deal with cleaning up or modifying the project for the betterment of it. |
`starter` | Applied by [Committers](#join-the-project-team) to issues that they consider good introductions to the project for people who have not contributed before. These are not necessarily "easy", but rather focused around how much context is necessary in order to understand what needs to be done for this project in particular. | Existing project members are expected to stay away from these unless they increase in priority.
`support` | This issue is either asking a question about how to use the project, clarifying the reason for unexpected behavior, or possibly reporting a `bug` but does not have enough detail yet to determine whether it would count as such. | The label should be switched to `bug` if reliable reproduction steps are provided. Issues primarily with unintended configurations of a user's environment are not considered bugs, even if they cause crashes.
`tests` | This issue or PR either requests or adds primarily tests to the project. | If a PR is pending tests, that will be handled through the [PR review process](#review-pull-requests)
`wontfix` | Labelers may apply this label to issues that clearly have nothing at all to do with the project or are otherwise entirely outside of its scope/sphere of influence. [Committers](#join-the-project-team) may apply this label and close an issue or PR if they decide to pass on an otherwise relevant issue. | The issue or PR should be closed as soon as the label is applied, and a clear explanation provided of why the label was used. Contributors are free to contest the labeling, but the decision ultimately falls on committers as to whether to accept something or not.
## Clean Up Issues and PRs
Issues and PRs can go stale after a while. Maybe they're abandoned. Maybe the team will just plain not have time to address them any time soon.
In these cases, they should be closed until they're brought up again or the interaction starts over.
To clean up issues and PRs:
* Search the issue tracker for issues or PRs, and add the term `updated:<=YYYY-MM-DD`, where the date is 30 days before today.
* Go through each issue *from oldest to newest*, and close them if **all of the following are true**:
* not opened by a maintainer
* not marked as `critical`
* not marked as `starter` or `help wanted` (these might stick around for a while, in general, as they're intended to be available)
* no explicit messages in the comments asking for it to be left open
* does not belong to a milestone
* Leave a message when closing saying "Cleaning up stale issue. Please reopen or ping us if and when you're ready to resume this. See https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/blob/latest/CONTRIBUTING.md#clean-up-issues-and-prs for more details."
## Review Pull Requests
While anyone can comment on a PR, add feedback, etc, PRs are only *approved* by team members with Issue Tracker or higher permissions.
PR reviews use [GitHub's own review feature](https://help.github.com/articles/about-pull-request-reviews/), which manages comments, approval, and review iteration.
Some notes:
* You may ask for minor changes ("nitpicks"), but consider whether they are really blockers to merging: try to err on the side of "approve, with comments".
* *ALL PULL REQUESTS* should be covered by a test: either by a previously-failing test, an existing test that covers the entire functionality of the submitted code, or new tests to verify any new/changed behavior. All tests must also pass and follow established conventions. Test coverage should not drop, unless the specific case is considered reasonable by maintainers.
* Please make sure you're familiar with the code or documentation being updated, unless it's a minor change (spellchecking, minor formatting, etc). You may @mention another project member who you think is better suited for the review, but still provide a non-approving review of your own.
* Be extra kind: people who submit code/doc contributions are putting themselves in a pretty vulnerable position, and have put time and care into what they've done (even if that's not obvious to you!) -- always respond with respect, be understanding, but don't feel like you need to sacrifice your standards for their sake, either. Just don't be a jerk about it?
## Merge Pull Requests
Project Team will merge pull requests after review.
## Tag A Release
Project Team will bump tags/version with [setver](https://github.com/pforret/setver) as a patch or minor versionupdate.
Releases are done manually for important changes.
## Join the Project Team
### Ways to Join
There are many ways to contribute! Most of them don't require any official status unless otherwise noted. That said, there's a couple of positions that grant special repository abilities, and this section describes how they're granted and what they do.
All of the below positions are granted based on the project team's needs, as well as their consensus opinion about whether they would like to work with the person and think that they would fit well into that position. The process is relatively informal, and it's likely that people who express interest in participating can just be granted the permissions they'd like.
You can spot a collaborator on the repo by looking for the `[Collaborator]` or `[Owner]` tags next to their names.
Permission | Description
--- | ---
Issue Tracker | Granted to contributors who express a strong interest in spending time on the project's issue tracker. These tasks are mainly [labeling issues](#label-issues), [cleaning up old ones](#clean-up-issues-and-prs), and [reviewing pull requests](#review-pull-requests), as well as all the usual things non-team-member contributors can do. Issue handlers should not merge pull requests, tag releases, or directly commit code themselves: that should still be done through the usual pull request process. Becoming an Issue Handler means the project team trusts you to understand enough of the team's process and context to implement it on the issue tracker.
Committer | Granted to contributors who want to handle the actual pull request merges, tagging new versions, etc. Committers should have a good level of familiarity with the codebase, and enough context to understand the implications of various changes, as well as a good sense of the will and expectations of the project team.
Admin/Owner | Granted to people ultimately responsible for the project, its community, etc.
## Attribution
This guide was generated using the WeAllJS `CONTRIBUTING.md` generator. [Make your own](https://npm.im/weallcontribute)!

21
LICENSE Normal file
View file

@ -0,0 +1,21 @@
MIT License
Copyright (c) 2021 Chris Titus, Matthias Morin
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

102
README.md
View file

@ -1,11 +1,97 @@
# Top 5 Bootloader Themes
Installation
![GH language](https://img.shields.io/github/languages/top/ChrisTitusTech/Top-5-Bootloader-Themes)
[![GH tag](https://img.shields.io/github/v/tag/ChrisTitusTech/Top-5-Bootloader-Themes)](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/tags)
[![GH release](https://img.shields.io/github/v/release/ChrisTitusTech/Top-5-Bootloader-Themes)](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/releases)
![GH license](https://img.shields.io/github/license/ChrisTitusTech/Top-5-Bootloader-Themes)
![GH stars](https://img.shields.io/github/stars/ChrisTitusTech/Top-5-Bootloader-Themes)
![Bash CI](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/workflows/bash_unit%20CI/badge.svg)
![Shellcheck CI](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/workflows/Shellcheck%20CI/badge.svg)
![visitors](https://visitor-badge.glitch.me/badge?page_id=ChrisTitusTech.Top-5-Bootloader-Themes)
```
git clone https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes
cd Top-5-Bootloader-Themes
sudo ./install.sh
ChrisTitusTech Top 5 Bootloader Themes
======================================
Install Bootloader Themes with ease.
- Chris Titus Tech Channel : [https://www.youtube.com/user/homergfunk](https://www.youtube.com/user/homergfunk)
- Chris Titus Tech YouTube Video : [Bootloader Themes | Install & Configuration](https://www.youtube.com/watch?v=BAyzHP1Cqb0)
- Full Walkthrough : [https://christitus.com/bootloader-themes](https://christitus.com/bootloader-themes)
🚀 Installation
---------------
Simply enter following commands in your terminal :
```bash
$ git clone https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes
$ cd Top-5-Bootloader-Themes
$ sudo ./install.sh
```
Full Walkthrough <https://christitus.com/bootloader-themes>
💻 Dependencies
---------------
**ChrisTitusTech Top 5 Bootloader Themes** requires the following dependencies:
- git
---
### 🔖 git
#### 🐧 Install git (Linux)
```bash
$ sudo apt-get install --assume-yes git
```
#### 🏁 Install git (Windows)
Download and install latest version from here [git-scm.com](https://git-scm.com/download/win)
#### 🍎 Install git (OSX)
```bash
$ brew install git
```
#### 🔧 git configuration
Push current branch only if upstream exists
```bash
$ git config --global push.default simple
```
Set vim as git default editor
```bash
$ git config --global core.editor 'vim'
```
🤝 Contributing
---------------
Thank you for your interest in contributing to **ChrisTitusTech Top 5 Bootloader Themes**.
Please review the [code of conduct](./CODE_OF_CONDUCT.md) and [contribution guidelines](./CONTRIBUTING.md) before starting to work on any features.
If you want to open an issue, please check first if it was not [reported already](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/issues) before creating a new one.
📜 License
----------
Copyrights (c) 2021 &quot;Chris Titus&quot; &lt;contact@christitus.com&gt; &amp; &quot;Matthias Morin&quot; &lt;mat@tangoman.io&gt;
[![License](https://img.shields.io/badge/Licence-MIT-green.svg)](LICENSE)
Distributed under the MIT license.
If you like **ChrisTitusTech Top 5 Bootloader Themes** please star, follow or tweet about it:
[![GitHub stars](https://img.shields.io/github/stars/ChrisTitusTech/Top-5-Bootloader-Themes?style=social)](https://github.com/ChrisTitusTech/Top-5-Bootloader-Themes/stargazers)
[![GitHub followers](https://img.shields.io/github/followers/ChrisTitusTech?style=social)](https://github.com/ChrisTitusTech)
[![Twitter](https://img.shields.io/twitter/url?style=social&url=https%3A%2F%2Fgithub.com%2FChrisTitusTech%2FTop-5-Bootloader-Themes)](https://twitter.com/intent/tweet?text=Wow:&url=https%3A%2F%2Fgithub.com%2FChrisTitusTech%2FTop-5-Bootloader-Themes)
🙏 Acknowledgements
-------------------
There is no obligation, but follow me ([TangoMan75](https://github.com/TangoMan75)) on GitHub and star some cool open source projects you like, it helps a lot. Thanks.

274
install.sh
View file

@ -1,133 +1,165 @@
#!/bin/bash
# Grub2 Theme
#/**
# * ChrisTechTips Grub2 Theme Installer
# *
# * @license MIT
# * @author "Chris Titus" <contact@christitus.com>
# * @author "Matthias Morin" <mat@tangoman.io>
# * @version 1.0.0
# * @link https://youtu.be/BAyzHP1Cqb0
# */
ROOT_UID=0
THEME_DIR="/usr/share/grub/themes"
PS3='Choose The Theme You Want: '
themes=("Vimix" "Cyberpunk" "Shodan" "fallout" "CyberRe" "Quit")
select THEME_NAME in "${themes[@]}"; do
case $THEME_NAME in
"Vimix")
echo "Installing Vimix to Boot"
break
;;
"Cyberpunk")
echo "Installing Cyberpunk to Boot"
break
;;
"Shodan")
echo "Installing Shodan to Boot"
break
;;
"fallout")
echo "Installing fallout to Boot"
break
;;
"CyberRe")
echo "Installing CyberRe to Boot"
break
;;
"Quit")
echo "User requested exit"
exit
;;
*) echo "invalid option $REPLY";;
esac
done
THEME_DIR='/usr/share/grub/themes'
THEME_NAME=''
MAX_DELAY=20 # max delay for user to enter root password
function echo_title() { echo -ne "\033[1;44;37m${*}\033[0m\n"; }
function echo_caption() { echo -ne "\033[0;1;44m${*}\033[0m\n"; }
function echo_bold() { echo -ne "\033[0;1;34m${*}\033[0m\n"; }
function echo_danger() { echo -ne "\033[0;31m${*}\033[0m\n"; }
function echo_success() { echo -ne "\033[0;32m${*}\033[0m\n"; }
function echo_warning() { echo -ne "\033[0;33m${*}\033[0m\n"; }
function echo_secondary() { echo -ne "\033[0;34m${*}\033[0m\n"; }
function echo_info() { echo -ne "\033[0;35m${*}\033[0m\n"; }
function echo_primary() { echo -ne "\033[0;36m${*}\033[0m\n"; }
function echo_error() { echo -ne "\033[0;1;31merror:\033[0;31m\t${*}\033[0m\n"; }
function echo_label() { echo -ne "\033[0;1;32m${*}:\033[0m\t"; }
function echo_prompt() { echo -ne "\033[0;36m${*}\033[0m "; }
#COLORS
CDEF=" \033[0m" # default color
CCIN=" \033[0;36m" # info color
CGSC=" \033[0;32m" # success color
CRER=" \033[0;31m" # error color
CWAR=" \033[0;33m" # waring color
b_CDEF=" \033[1;37m" # bold default color
b_CCIN=" \033[1;36m" # bold info color
b_CGSC=" \033[1;32m" # bold success color
b_CRER=" \033[1;31m" # bold error color
b_CWAR=" \033[1;33m" # bold warning color
# echo like ... with flag type and display message colors
prompt () {
case ${1} in
"-s"|"--success")
echo -e "${b_CGSC}${@/-s/}${CDEF}";; # print success message
"-e"|"--error")
echo -e "${b_CRER}${@/-e/}${CDEF}";; # print error message
"-w"|"--warning")
echo -e "${b_CWAR}${@/-w/}${CDEF}";; # print warning message
"-i"|"--info")
echo -e "${b_CCIN}${@/-i/}${CDEF}";; # print info message
*)
echo -e "$@"
;;
esac
function splash() {
local hr
hr=" **$(printf "%${#1}s" | tr ' ' '*')** "
echo_title "${hr}"
echo_title " * $1 * "
echo_title "${hr}"
echo
}
# Welcome message
prompt -s "\n\t*************************\n\t* ${THEME_NAME} - Grub2 Theme *\n\t*************************"
# Check command avalibility
function has_command() {
command -v $1 > /dev/null
}
prompt -w "\nChecking for root access...\n"
# Checking for root access and proceed if it is present
if [ "$UID" -eq "$ROOT_UID" ]; then
# Create themes directory if not exists
prompt -i "\nChecking for the existence of themes directory...\n"
[[ -d ${THEME_DIR}/${THEME_NAME} ]] && rm -rf ${THEME_DIR}/${THEME_NAME}
mkdir -p "${THEME_DIR}/${THEME_NAME}"
# Copy theme
prompt -i "\nInstalling ${THEME_NAME} theme...\n"
cp -a themes/${THEME_NAME}/* ${THEME_DIR}/${THEME_NAME}
# Set theme
prompt -i "\nSetting ${THEME_NAME} as default...\n"
# Backup grub config
cp -an /etc/default/grub /etc/default/grub.bak
grep "GRUB_THEME=" /etc/default/grub 2>&1 >/dev/null && sed -i '/GRUB_THEME=/d' /etc/default/grub
echo "GRUB_THEME=\"${THEME_DIR}/${THEME_NAME}/theme.txt\"" >> /etc/default/grub
# Update grub config
echo -e "Updating grub config..."
if has_command update-grub; then
update-grub
elif has_command grub-mkconfig; then
grub-mkconfig -o /boot/grub/grub.cfg
elif has_command grub2-mkconfig; then
if has_command zypper; then
grub2-mkconfig -o /boot/grub2/grub.cfg
elif has_command dnf; then
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
function check_root() {
# Checking for root access and proceed if it is present
ROOT_UID=0
if [[ ! "${UID}" -eq "${ROOT_UID}" ]]; then
# Error message
echo_error 'Run me as root.'
echo_info 'try sudo ./install.sh'
exit 1
fi
fi
}
# Success message
prompt -s "\n\t ***************\n\t * All done! *\n\t ***************\n"
function select_theme() {
themes=('Vimix' 'Cyberpunk' 'Shodan' 'fallout' 'CyberRe' 'Quit')
else
PS3=$(echo_prompt '\nChoose The Theme You Want: ')
select THEME_NAME in "${themes[@]}"; do
case "${THEME_NAME}" in
'Vimix')
splash 'Installing Vimix Theme'
break;;
'Cyberpunk')
splash 'Installing Cyberpunk Theme'
break;;
'Shodan')
splash 'Installing Shodan Theme'
break;;
'fallout')
splash 'Installing fallout Theme'
break;;
'CyberRe')
splash 'Installing CyberRe Theme'
break;;
'Quit')
echo_info 'User requested exit'
exit 0;;
*) echo_warning "invalid option \"${REPLY}\"";;
esac
done
}
# Error message
prompt -e "\n [ Error! ] -> Run me as root "
function backup() {
# Backup grub config
echo_info 'cp -an /etc/default/grub /etc/default/grub.bak'
cp -an /etc/default/grub /etc/default/grub.bak
}
# persisted execution of the script as root
read -p "[ trusted ] specify the root password : " -t${MAX_DELAY} -s
[[ -n "$REPLY" ]] && {
sudo -S <<< $REPLY $0
} || {
prompt "\n Operation canceled Bye"
exit 1
}
fi
function install_theme() {
# create themes directory if not exists
if [[ ! -d "${THEME_DIR}/${THEME_NAME}" ]]; then
# Copy theme
echo_primary "Installing ${THEME_NAME} theme..."
echo_info "mkdir -p \"${THEME_DIR}/${THEME_NAME}\""
mkdir -p "${THEME_DIR}/${THEME_NAME}"
echo_info "cp -a ./themes/\"${THEME_NAME}\"/* \"${THEME_DIR}/${THEME_NAME}\""
cp -a ./themes/"${THEME_NAME}"/* "${THEME_DIR}/${THEME_NAME}"
fi
}
function config_grub() {
echo_primary 'Enabling grub menu'
# remove default grub style if any
echo_info "sed -i '/GRUB_TIMEOUT_STYLE=/d' /etc/default/grub"
sed -i '/GRUB_TIMEOUT_STYLE=/d' /etc/default/grub
echo_info "echo 'GRUB_TIMEOUT_STYLE=\"menu\"' >> /etc/default/grub"
echo 'GRUB_TIMEOUT_STYLE="menu"' >> /etc/default/grub
#--------------------------------------------------
echo_primary 'Setting grub timeout to 10 seconds'
# remove default timeout if any
echo_info "sed -i '/GRUB_TIMEOUT=/d' /etc/default/grub"
sed -i '/GRUB_TIMEOUT=/d' /etc/default/grub
echo_info "echo 'GRUB_TIMEOUT=\"10\"' >> /etc/default/grub"
echo 'GRUB_TIMEOUT="10"' >> /etc/default/grub
#--------------------------------------------------
echo_primary "Setting ${THEME_NAME} as default"
# remove theme if any
echo_info "sed -i '/GRUB_THEME=/d' /etc/default/grub"
sed -i '/GRUB_THEME=/d' /etc/default/grub
echo_info "echo \"GRUB_THEME=\"${THEME_DIR}/${THEME_NAME}/theme.txt\"\" >> /etc/default/grub"
echo "GRUB_THEME=\"${THEME_DIR}/${THEME_NAME}/theme.txt\"" >> /etc/default/grub
}
function update_grub() {
# Update grub config
echo_primary 'Updating grub config...'
if [[ -x "$(command -v update-grub)" ]]; then
echo_info 'update-grub'
update-grub
elif [[ -x "$(command -v grub-mkconfig)" ]]; then
echo_info 'grub-mkconfig -o /boot/grub/grub.cfg'
grub-mkconfig -o /boot/grub/grub.cfg
elif [[ -x "$(command -v grub2-mkconfig)" ]]; then
if [[ -x "$(command -v zypper)" ]]; then
echo_info 'grub2-mkconfig -o /boot/grub2/grub.cfg'
grub2-mkconfig -o /boot/grub2/grub.cfg
elif [[ -x "$(command -v dnf)" ]]; then
echo_info 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg'
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
fi
fi
}
function main() {
splash 'ChrisTechTips Grub2 Theme Installer'
check_root
select_theme
install_theme
config_grub
update_grub
echo_success 'All done !'
}
main

37
run_linter.sh Executable file
View file

@ -0,0 +1,37 @@
#!/bin/bash
#/**
# * TangoMan shellcheck linter
# *
# * @license MIT
# * @author "Matthias Morin" <mat@tangoman.io>
# */
function echo_title() { echo -ne "\033[1;44;37m${*}\033[0m\n"; }
function echo_caption() { echo -ne "\033[0;1;44m${*}\033[0m\n"; }
function echo_bold() { echo -ne "\033[0;1;34m${*}\033[0m\n"; }
function echo_danger() { echo -ne "\033[0;31m${*}\033[0m\n"; }
function echo_success() { echo -ne "\033[0;32m${*}\033[0m\n"; }
function echo_warning() { echo -ne "\033[0;33m${*}\033[0m\n"; }
function echo_secondary() { echo -ne "\033[0;34m${*}\033[0m\n"; }
function echo_info() { echo -ne "\033[0;35m${*}\033[0m\n"; }
function echo_primary() { echo -ne "\033[0;36m${*}\033[0m\n"; }
function echo_error() { echo -ne "\033[0;1;31merror:\033[0;31m\t${*}\033[0m\n"; }
function echo_label() { echo -ne "\033[0;1;32m${*}:\033[0m\t"; }
function echo_prompt() { echo -ne "\033[0;36m${*}\033[0m "; }
clear
echo_title ' ############################## '
echo_title ' # TangoMan Shellcheck Linter # '
echo_title ' ############################## '
echo
if [ ! -x "$(command -v shellcheck)" ]; then
echo_error "\"$(basename "${0}")\" requires shellcheck, try: 'sudo apt-get install -y shellcheck'"
exit 1
fi
echo_info "find . -name '*.sh' | sort -t '\0' -n | xargs shellcheck"
find . -name '*.sh' | sort -t '\0' -n | xargs shellcheck

80
run_tests.sh Executable file
View file

@ -0,0 +1,80 @@
#!/bin/bash
#/**
# * TangoMan Test Runner
# *
# * Runs tests in test directory with bash_unit
# *
# * @licence MIT
# * @author "Matthias Morin" <mat@tangoman.io>
# */
function echo_title() { echo -ne "\033[1;44;37m${*}\033[0m\n"; }
function echo_caption() { echo -ne "\033[0;1;44m${*}\033[0m\n"; }
function echo_bold() { echo -ne "\033[0;1;34m${*}\033[0m\n"; }
function echo_danger() { echo -ne "\033[0;31m${*}\033[0m\n"; }
function echo_success() { echo -ne "\033[0;32m${*}\033[0m\n"; }
function echo_warning() { echo -ne "\033[0;33m${*}\033[0m\n"; }
function echo_secondary() { echo -ne "\033[0;34m${*}\033[0m\n"; }
function echo_info() { echo -ne "\033[0;35m${*}\033[0m\n"; }
function echo_primary() { echo -ne "\033[0;36m${*}\033[0m\n"; }
function echo_error() { echo -ne "\033[0;1;31merror:\033[0;31m\t${*}\033[0m\n"; }
function echo_label() { echo -ne "\033[0;1;32m${*}:\033[0m\t"; }
function echo_prompt() { echo -ne "\033[0;36m${*}\033[0m "; }
test_directory="$(realpath "$(pwd)")/tests"
clear
echo_title ' ######################## '
echo_title ' # TangoMan Test Runner # '
echo_title ' ######################## '
echo
if [ ! -d "${test_directory}" ]; then
mkdir -p "${test_directory}"
cat > "${test_directory}/test_bash.sh" <<EOF
#!/bin/bash
# https://github.com/pgrange/bash_unit
#
# assert "test -e /tmp/the_file"
# assert_fails "grep this /tmp/the_file" "should not write 'this' in /tmp/the_file"
# assert_status_code 25 code
# assert_equals "a string" "another string" "a string should be another string"
# assert_not_equals "a string" "a string" "a string should be different from another string"
# fake ps echo hello world
test_can_fail() {
fail "You need to write some tests"
}
EOF
fi
if [ ! -f "${test_directory}/bash_unit" ]; then
if [ -x "$(command -v wget)" ]; then
echo_info "wget -qO \"${test_directory}/bash_unit\" https://raw.githubusercontent.com/pgrange/bash_unit/master/bash_unit"
wget -qO "${test_directory}/bash_unit" https://raw.githubusercontent.com/pgrange/bash_unit/master/bash_unit
elif [ -x "$(command -v curl)" ]; then
echo_info "curl -sSL -o \"${test_directory}/bash_unit\" https://raw.githubusercontent.com/pgrange/bash_unit/master/bash_unit"
curl -sSL -o "${test_directory}/bash_unit" https://raw.githubusercontent.com/pgrange/bash_unit/master/bash_unit
else
echo_error "could not find \"bash_unit\" executable, please install manually"
exit 1
fi
fi
if [ ! -x "${test_directory}/bash_unit" ]; then
echo_info "chmod +x \"${test_directory}\"/bash_unit"
chmod +x "${test_directory}"/bash_unit
fi
echo_info "cd \"${test_directory}\" || exit 1"
cd "${test_directory}" || exit 1
echo_info './bash_unit -f tap test_*'
./bash_unit -f tap test_*

381
tests/bash_unit Executable file
View file

@ -0,0 +1,381 @@
#!/usr/bin/env bash
#
# bash unit testing enterprise edition framework for professionals
# Copyright (C) 2011-2016 Pascal Grange
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
#
# https://github.com/pgrange/bash_unit
VERSION=v1.7.1
ESCAPE=$(printf "\033")
NOCOLOR="${ESCAPE}[0m"
RED="${ESCAPE}[91m"
GREEN="${ESCAPE}[92m"
YELLOW="${ESCAPE}[93m"
BLUE="${ESCAPE}[94m"
# Make bash_unit immune to some basic unix commands faking
CAT="$(which cat)"
SED="$(which sed)"
GREP="$(which grep)"
RM="$(which rm)"
fail() {
local message=${1:-}
local stdout=${2:-}
local stderr=${3:-}
notify_test_failed "$__bash_unit_current_test__" "$message"
[[ ! -z $stdout ]] && [ -s "$stdout" ] && notify_stdout < "$stdout"
[[ ! -z $stderr ]] && [ -s "$stderr" ] && notify_stderr < "$stderr"
stacktrace | notify_stack
exit 1
}
assert() {
local assertion=$1
local message=${2:-}
_assert_expression \
"$assertion" \
"[ \$status == 0 ]" \
"\"$message\""
}
assert_fails() {
local assertion=$1
local message=${2:-}
_assert_expression \
"$assertion" \
"[ \$status != 0 ]" \
"\"$message\""
}
assert_fail() {
#deprecated, use assert_fails instead
assert_fails "$@"
}
assert_status_code() {
local expected_status=$1
local assertion="$2"
local message="${3:-}"
_assert_expression \
"$assertion" \
"[ \$status == $expected_status ]" \
"\"$message\" expected status code $expected_status but was \$status"
}
_assert_expression() {
local assertion=$1
local condition=$2
local message=$3
(
local stdout=$(mktemp)
local stderr=$(mktemp)
trap "$RM -f \"$stdout\" \"$stderr\"" EXIT
local status
eval "($assertion)" >"$stdout" 2>"$stderr" && status=$? || status=$?
if ! eval "$condition"
then
fail "$(eval echo $message)" "$stdout" "$stderr"
fi
) || exit $?
}
assert_equals() {
local expected=$1
local actual=$2
local message=${3:-}
[[ -z $message ]] || message="$message\n"
if [ "$expected" != "$actual" ]
then
fail "$message expected [$expected] but was [$actual]"
fi
}
assert_not_equals() {
local unexpected=$1
local actual=$2
local message=${3:-}
[[ -z $message ]] || message="$message\n"
[ "$unexpected" != "$actual" ] || \
fail "$message expected different value than [$unexpected] but was the same"
}
fake() {
local command=$1
shift
if [ $# -gt 0 ]
then
eval "function $command() { export FAKE_PARAMS=\"\$@\" ; $@ ; }"
else
eval "function $command() { echo \"$($CAT)\" ; }"
fi
export -f $command
}
stacktrace() {
local i=1
while ! [ -z "${BASH_SOURCE[$i]:-}" ]
do
echo ${BASH_SOURCE[$i]}:${BASH_LINENO[$((i-1))]}:${FUNCNAME[$i]}\(\)
i=$((i + 1))
done | "$GREP" -v "^$BASH_SOURCE"
}
run_test_suite() {
local failure=0
declare -F | "$GREP" ' setup_suite$' >/dev/null && setup_suite
for pending_test in $(set | "$GREP" -E '^(pending|todo).* \(\)' | "$GREP" -E "$test_pattern" | "$SED" -e 's: .*::')
do
notify_test_starting "$pending_test"
notify_test_pending "$pending_test"
done
for test in $(set | "$GREP" -E '^test.* \(\)' | "$GREP" -E "$test_pattern" | "$SED" -e 's: .*::')
do
(
local status=0
declare -F | "$GREP" ' setup$' >/dev/null && setup
(__bash_unit_current_test__="$test" run_test) || status=$?
declare -F | "$GREP" ' teardown$' >/dev/null && teardown
exit $status
)
failure=$(( $? || failure))
done
declare -F | "$GREP" ' teardown_suite$' >/dev/null && teardown_suite
return $failure
}
run_test() {
set -e
notify_test_starting "$__bash_unit_current_test__"
"$__bash_unit_current_test__" && notify_test_succeeded "$__bash_unit_current_test__"
}
usage() {
echo "$1" >&2
echo "$0 [-f <output format>] [-p <pattern1>] [-p <pattern2>]... <test_file1> <test_file2>..." >&2
echo >&2
echo "Runs tests in test files that match <pattern>s" >&2
echo "<output format> is optional only supported value is tap" >&2
echo "-v to get current version information" >&2
echo "See https://github.com/pgrange/bash_unit" >&2
exit 1
}
# Formating
pretty_success() {
pretty_format "$GREEN" "\u2713" "${1:-}"
}
pretty_warning() {
pretty_format "$YELLOW" "\u2717" "$1"
}
pretty_failure() {
pretty_format "$RED" "\u2717" "${1:-}"
}
pretty_format() {
local color="$1"
local pretty_symbol="$2"
local alt_symbol="$3"
local term_utf8=false
if is_terminal && [[ "$LANG" =~ .*UTF-8.* ]]
then
term_utf8=true
fi
(
$CAT
if $term_utf8
then
echo -en " $pretty_symbol "
else
[[ ! -z "$alt_symbol" ]] && echo -en " $alt_symbol "
fi
) | color "$color"
}
color() {
_start_color() {
if is_terminal ; then echo -en "$color" ; fi
}
_stop_color() {
if is_terminal ; then echo -en "$NOCOLOR" ; fi
}
local color=$1
shift
_start_color
if [ $# -gt 0 ]
then
echo $*
else
$CAT
fi
_stop_color
}
is_terminal() {
[ -t 1 ] || [[ "${FORCE_COLOR}" == true ]]
}
text_format() {
notify_suite_starting() {
local test_file="$1"
echo "Running tests in $test_file"
}
notify_test_starting() {
local test="$1"
echo -n "Running $test... " | color "$BLUE"
}
notify_test_pending() {
echo -n "PENDING" | pretty_warning
echo
}
notify_test_succeeded() {
echo -n "SUCCESS" | pretty_success
echo
}
notify_test_failed() {
local message="$2"
echo -n "FAILURE" | pretty_failure
echo
[[ -z $message ]] || printf -- "$message\n"
}
notify_stdout() {
"$SED" 's:^:out> :' | color "$GREEN"
}
notify_stderr() {
"$SED" 's:^:err> :' | color "$RED"
}
notify_stack() {
color "$YELLOW"
}
}
tap_format() {
notify_suite_starting() {
local test_file="$1"
echo "# Running tests in $test_file"
}
notify_test_starting() {
echo -n
}
notify_test_pending() {
local test="$1"
echo -n "ok" | pretty_warning -
echo -n "$test" | color "$BLUE"
echo " # skip test to be written" | color "$YELLOW"
}
notify_test_succeeded() {
local test="$1"
echo -n "ok" | pretty_success -
echo "$test" | color "$BLUE"
}
notify_test_failed() {
local test="$1"
local message="$2"
echo -n "not ok" | pretty_failure -
echo "$test" | color "$BLUE"
[[ -z $message ]] || printf -- "$message\n" | "$SED" -u -e 's/^/# /'
}
notify_stdout() {
"$SED" 's:^:# out> :' | color "$GREEN"
}
notify_stderr() {
"$SED" 's:^:# err> :' | color "$RED"
}
notify_stack() {
"$SED" 's:^:# :' | color "$YELLOW"
}
}
output_format=text
test_pattern=""
separator=""
while getopts "vp:f:" option
do
case "$option" in
p)
test_pattern="${test_pattern}${separator}${OPTARG}"
separator="|"
;;
f)
output_format="${OPTARG}"
;;
v)
echo "bash_unit $VERSION"
exit
;;
?|:)
usage
;;
esac
done
shift $((OPTIND-1))
for test_file in "$@"
do
test -e "$test_file" || usage "file does not exist: $test_file"
test -r "$test_file" || usage "can not read file: $test_file"
done
case "$output_format" in
text)
text_format
;;
tap)
tap_format
;;
*)
usage "unsupproted output format: $output_format"
;;
esac
#run tests received as parameters
failure=0
for test_file in "$@"
do
notify_suite_starting "$test_file"
(
set -e # Ensure bash_unit with exit with failure
# in case of syntax error.
if [[ "${STICK_TO_CWD}" != true ]]
then
cd "$(dirname "$test_file")"
source "$(basename "$test_file")"
else
source "$test_file"
fi
set +e
run_test_suite
)
failure=$(( $? || failure))
done
exit $failure

17
tests/test_install.sh Normal file
View file

@ -0,0 +1,17 @@
#!/bin/bash
# https://github.com/pgrange/bash_unit
#
# assert "test -e /tmp/the_file"
# assert_fails "grep this /tmp/the_file" "should not write 'this' in /tmp/the_file"
# assert_status_code 25 code # 127: command not found; 126: command not executable
# assert_equals "a string" "another string" "a string should be another string"
# assert_not_equals "a string" "a string" "a string should be different from another string"
# fake ps echo hello world
src_file="../install.sh"
test_script_execution_should_return_expected_status_code() {
# script should be run with root privileges
assert_status_code 1 "${src_file}"
}