tracee
tracee copied to clipboard
docs: remove $ from code examples
Issue: #2184
Simple find and replace with regex ^$\s applied on docs/
Initial Checklist
- [x] There is an issue describing the need for this PR.
- [x] Git log contains summary of the change.
- [x] Git log contains motivation and context of the change.
- [ ] If part of an EPIC, PR git log contains EPIC number.
- [ ] If part of an EPIC, PR was added to EPIC description.
Description (git log)
commit cadf4e64aad3aca107389d5253f424a310626203 (HEAD -> docs/remove_dollar)
Author: danieled-it <[email protected]>
Date: Wed Sep 21 18:39:34 2022 +0200
docs: remove $ from code examples
Issue: #2184
Simple find and replace with regex ^\$\s applied on docs/
(Please consider that trailing whitespaces got caught in the process, I don't think that should be an issue though)
Fixes: #2184
Type of change
- [ ] Bug fix (non-breaking change fixing an issue, preferable).
- [x] Quick fix (minor non-breaking change requiring no issue, use with care)
- [ ] Code refactor (code improvement and/or code removal)
- [ ] New feature (non-breaking change adding functionality).
- [ ] Breaking change (cause existing functionality not to work as expected).
How Has This Been Tested?
Tests being included in this PR:
N/A
Reproduce the test by running:
N/A
Final Checklist:
Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.
- [ ] I have made corresponding changes to the documentation.
- [ ] My code follows the style guidelines (C and Go) of this project.
- [ ] I have performed a self-review of my own code.
- [ ] I have commented all functions/methods created explaining what they do.
- [ ] I have commented my code, particularly in hard-to-understand areas.
- [ ] My changes generate no new warnings.
- [ ] I have added tests that prove my fix, or feature, is effective.
- [ ] New and existing unit tests pass locally with my changes.
- [ ] Any dependent changes have been merged and published before.
Git Log Checklist:
My commits logs have:
- [x] Subject starts with "subsystem|file: description".
- [x] Do not end the subject line with a period.
- [x] Limit the subject line to 50 characters.
- [x] Separate subject from body with a blank line.
- [x] Use the imperative mood in the subject line.
- [x] Wrap the body at 72 characters.
- [x] Use the body to explain what and why instead of how.
@josedonizetti I see, a bunch of code blocks are tab-indented in different files, those were totally missed and I can check them all manually, but I don't see any particular example of "some others where perhaps we should not change", can you give me some example? Glad to work on those too!
@rafaeldtinoco totally got it now, I'm undo-ing the sed and going on manually in the different pages with the browser on the other side of the screen to check them 😃
Question: I guess those examples referring to in-container execution should stay untouched, right? Like:
make -f builder/Makefile.tracee-make alpine-prepare
make -f builder/Makefile.tracee-make alpine-shell
tracee@f64bb4a2f0b1[/tracee]$ make clean
tracee@f64bb4a2f0b1[/tracee]$ make tracee-ebpf
tracee@f64bb4a2f0b1[/tracee]$ sudo ./dist/tracee-ebpf \
-o option:parse-arguments \
--trace comm=bash \
--trace follow
Question: I guess those examples referring to in-container execution should stay untouched, right? Like:
I believe so. I wanted to show we were inside the container (could not think anything better than showing the random hostnames).
Thanks a lot for taking time to go through this, really appreciate!
hey, sorry this is taking me so long, it's supposed to be "an easy fix" but I had almost no time to dedicate to this these past days (perks of no longer being 20 or so, I guess 🧓🏻 )
I think I'm at a pretty good point, the only entries which don't convince me much when the dollar sign is removed are the
```console
ones, those are including valuable outputs and it's easy to misunderstand what's going on if the dollar is removed, I'd tend to keep it there unless you think separating command and output blocks makes sense, what do you think?
@josedonizetti with the documentation changes we've made recently... maybe we should do the same changes as proposed here ?
Unfortunately there are many conflicts now for this to be worth rebasing I believe...
@danieled-it Really sorry for not giving prompt feedback here, but with the kubecon deadline, we were really rushing to deliver the new release. Are you still interested on helping, I definitely have a better idea of what to do in the docs now, to help finish this. Though it would be best to start a new PR, maybe doing small changes (a couple of pages per time) so it is easier to review and merge.
Closing this one per last comment. Sorry for the trouble, again.