Conversation
…ould not be OR but both
yarikoptic
left a comment
yarikoptic
left a comment
There was a problem hiding this comment.
Thank you @jdkent ! I don't know how I have missed this wonderful PR ;-)
I left some comments behind and pushed some commits you are welcome to remove/adjust.
| set -o emacs # use the emacs shortcuts | ||
|
|
||
| # function to help remind users about the shortcuts | ||
| print_shortcuts() { |
There was a problem hiding this comment.
I have tested -- we could even use ? for the name of this function. I am just afraid that we all (I for sure) would forget what is the name (print_shortcuts). If at least it would become repronim specific (e.g. repronim_bashrc_help) then I could use completion to arrive to it.
There was a problem hiding this comment.
I think I like repronim_bashrc_help because the question mark could have unexpected behavior
code/.repronim.bashrc
Outdated
| # function to help remind users about the shortcuts | ||
| print_shortcuts() { | ||
| LINE="Commandline/Cursor Editing Shortcuts:: | ||
| Ctrl-a: Go to the beginning of the line you are currently typing on |
There was a problem hiding this comment.
Why not to indent all those items but at least one space -- otherwise it clutters visual appearance IMHO
There was a problem hiding this comment.
ok, did it in 9792157, please revert/drop if you feel that it is not desired
code/.repronim.bashrc
Outdated
| Alt-f: Move cursor forward one word on the current line | ||
| Alt-b: Move cursor backward one word on the current line | ||
| Tab: Auto-complete files, folders, and command names | ||
| Ctrl-x OR Ctrl-e OR Alt-e in zsh: Edit command line text in the editor (as defined by VISUAL environment variable)" |
There was a problem hiding this comment.
pushed the fix (3b059b9), should be Ctrl-x Ctrl-e (not either of those but both in sequence)
|
|
||
|
|
||
| # create an eternal bash history file | ||
| # https://debian-administration.org/article/543/Bash_eternal_history |
There was a problem hiding this comment.
have you use this one personally @jdkent? I just have no personal experience with this one yet
There was a problem hiding this comment.
the eternal bash history appears to just be a fail safe when the command is older than .bash_history holds. i played with cntrl+r and it does not use .bash_eternal_history, just the number of commands in history stored in memory (not in a file). You have to interact with the file directly to search for old commands (e.g. cat ~/.bash_eternal_history | grep "string").
| > (e.g. you can copy this file to your home directory and add `source ~/.repronim.bashrc` | ||
| > to your original `.bashrc` file) | ||
| > or you can copy/paste useful lines from this file to your `.bashrc`. | ||
| {: .callout} |
There was a problem hiding this comment.
Whatever teaching VM/environment we provide next time, we should make sure to include this .bashrc ;-)!
|
FWIW, for the I think it might make sense for me even to adopt this bashrc in its entirety (with the history etc) within that (sub)project -- could be used as a demo case etc with a wide range of containers which are/will be provided by that |
…ive sessions **Related** This is a prototype for functionality which might be of interest outside of this project, e.g. related: - regular `datalad run` to record activities in the shell. - [`run --interactive`](datalad/datalad#2158 (comment)) - [`run --shell`](datalad/datalad#2275) so here I am "implementing" it, solely for containerized environments ATM, via a "over the head" communication to the shim in environment variable - `datalad run` for better record keeping, e.g. - [saving stdout/err](datalad/datalad#3385) so here I was not bothering to establish stdout/err capture but possibly could and might - `reproman login`, or even `execute` (with or without --trace) and may be `run` where we could benefit from having an environment with a unified interface for interactive sessions which would also establish the record of activities - just a regular shell environment to make a clear record of commands which were ran - might eventually absorb/meld with the "opinionated .bashrc" proposed for the training curiculum: ReproNim/module-reproducible-basics#26 which provides assistance/docs for more efficient use of cmdline and establishes 'infinite bash history'. **reproshell???** So it feels to me like a motivation for some kind of a reproshell independent project which would be - usable indepdendently and easily installable/bindable (e.g. into a container) - parametrizeable to be invoked from the shim here and/or by datalad or reproman so could just take care about capturing all sidecar files into specified locations **Could benefit from** - knowing more about "datalad (containers-)run" invocation Implemented now within `singularity_run` shim, which could have benefited from having additional information about how exactly it was `ran` and also to instruct datalad run "upstairs" that there is now an additional file in [extra_outputs](datalad/datalad#3094). Hence there is datalad/datalad#3422 - [`datalad run` being able to 'cover' multiple commits](datalad/datalad#3265) Interactivity creates ambiguity for `rerun` semantic: - run record ATM would say "reinvoke interactive session" which might be desireable on its own (e.g. to redo something manually in that original container) - but for "automated reproducibility" we do have all information (bash history file, which is a list of commands to run) possibly recorded in another commit, which is ATM is not associated with the "run" record So may be with somehow [tagging run commits](datalad/datalad#3371) it could be possible to disambiguate/select specific run commits/records? **Example** **Additional possible features which might come here into a prototype** - color info/error messages from the shim - indicate being [reproman --trace](ReproNim/reproman#416 - provide 'reactive' PS1 to alert user when he/she leaves the initial directory (thus the one outside of original dataset), possibly resulting in outputs which would not be recorded
…ive sessions **Related** This is a prototype for functionality which might be of interest outside of this project, e.g. related: - regular `datalad run` to record activities in the shell. - [`run --interactive`](datalad/datalad#2158 (comment)) - [`run --shell`](datalad/datalad#2275) so here I am "implementing" it, solely for containerized environments ATM, via a "over the head" communication to the shim in environment variable - `datalad run` for better record keeping, e.g. - [saving stdout/err](datalad/datalad#3385) so here I was not bothering to establish stdout/err capture but possibly could and might - `reproman login`, or even `execute` (with or without --trace) and may be `run` where we could benefit from having an environment with a unified interface for interactive sessions which would also establish the record of activities - just a regular shell environment to make a clear record of commands which were ran - might eventually absorb/meld with the "opinionated .bashrc" proposed for the training curiculum: ReproNim/module-reproducible-basics#26 which provides assistance/docs for more efficient use of cmdline and establishes 'infinite bash history'. **reproshell???** So it feels to me like a motivation for some kind of a reproshell independent project which would be - usable indepdendently and easily installable/bindable (e.g. into a container) - parametrizeable to be invoked from the shim here and/or by datalad or reproman so could just take care about capturing all sidecar files into specified locations **Could benefit from** - knowing more about "datalad (containers-)run" invocation Implemented now within `singularity_run` shim, which could have benefited from having additional information about how exactly it was `ran` and also to instruct datalad run "upstairs" that there is now an additional file in [extra_outputs](datalad/datalad#3094). Hence there is datalad/datalad#3422 - [`datalad run` being able to 'cover' multiple commits](datalad/datalad#3265) Interactivity creates ambiguity for `rerun` semantic: - run record ATM would say "reinvoke interactive session" which might be desireable on its own (e.g. to redo something manually in that original container) - but for "automated reproducibility" we do have all information (bash history file, which is a list of commands to run) possibly recorded in another commit, which is ATM is not associated with the "run" record So may be with somehow [tagging run commits](datalad/datalad#3371) it could be possible to disambiguate/select specific run commits/records? <details> <summary>**Example**</summary> (dev) 1 13348.....................................:Wed 15 May 2019 06:12:24 PM EDT:. (git-annex)hopa:~/proj/repronim/containers[enh-shell]git-annex $> SINGULARITY_CMD=shell datalad containers-run -n repronim-reproin [INFO ] Making sure inputs are available (this may take some time) [INFO ] == Command start (output follows) ===== <ome/yoh/proj/repronim/containers$ echo "I will do something useful today" I will do something useful today singularity:repronim-reproin > yoh@hopa:/home/yoh/proj/repronim/containers$ touch my-results singularity:repronim-reproin > yoh@hopa:/home/yoh/proj/repronim/containers$ cd images/ singularity:repronim-reproin > yoh@hopa:/home/yoh/proj/repronim/containers/images$ ls bids README.md repronim singularity:repronim-reproin > yoh@hopa:/home/yoh/proj/repronim/containers/images$ cd ../ singularity:repronim-reproin > yoh@hopa:/home/yoh/proj/repronim/containers$ ls binds images LICENSE my-results README.md scripts <pa:/home/yoh/proj/repronim/containers$ rm LICENSE ; echo 'nobody needs those' nobody needs those singularity:repronim-reproin > yoh@hopa:/home/yoh/proj/repronim/containers$ exit add(ok): .repronim/bash_histories/0.1-3-ge25c927-2019-05-15T18:12:37-04:00 (file) save(ok): . (dataset) action summary: add (ok: 1) save (ok: 1) [INFO ] == Command exit (modification check follows) ===== delete(ok): LICENSE (file) add(ok): my-results (file) save(ok): . (dataset) action summary: add (ok: 1) delete (ok: 1) get (notneeded: 1) save (ok: 1) SINGULARITY_CMD=shell datalad containers-run -n repronim-reproin 3.42s user 1.74s system 9% cpu 54.068 total $> git log --stat HEAD^^.. commit 89fed08617418e5ddb88ae11ee2c14db699acf31 (HEAD -> enh-shell) Author: Yaroslav Halchenko <[email protected]> Date: Wed May 15 18:13:28 2019 -0400 [DATALAD RUNCMD] ./scripts/singularity_cmd run images/rep... === Do not change lines below === { "chain": [], "cmd": "./scripts/singularity_cmd run images/repronim/repronim-reproin--0.5.4.sing ", "dsid": "b02e63c2-62c1-11e9-82b0-52540040489c", "exit": 0, "extra_inputs": [], "inputs": [ "images/repronim/repronim-reproin--0.5.4.sing" ], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^ LICENSE | 201 --------------------------------------------------------------------------------------------- my-results | 1 + 2 files changed, 1 insertion(+), 201 deletions(-) commit 5aa3b3383c2746f7c1d07ecdcc73852eb0a30f17 Author: Yaroslav Halchenko <[email protected]> Date: Wed May 15 18:13:28 2019 -0400 [REPRONIM/CONTAINERS]: bash history for the interactive session Actual changes might (or not, depending on the invocation) get committed in the next commit .repronim/bash_histories/0.1-3-ge25c927-2019-05-15T18:12:37-04:00 | 7 +++++++ 1 file changed, 7 insertions(+) $> cat .repronim/bash_histories/0.1-3-ge25c927-2019-05-15T18:12:37-04:00 echo "I will do something useful today" touch my-results cd images/ ls cd ../ ls rm LICENSE ; echo 'nobody needs those' </details> **Additional possible features which might come here into a prototype** - color info/error messages from the shim - improve PS1 (probably multiline -- too much in a single line to still be able edit commands) - indicate being [reproman --trace](ReproNim/reproman#416 - provide 'reactive' PS1 to alert user when he/she leaves the initial directory (thus the one outside of original dataset), possibly resulting in outputs which would not be recorded
|
As I have described a bit in ReproNim/containers#9 it might make sense to actually establish a "reproshell" project @jdkent which would provide a flexible and "pluggable" shell configuration which we then could reuse across a wide(r) range of projects or which could serve as a standalone one for ppl to use, and to be recommended here. |
|
Hi @jdkent , we seems forgot about this lovely PR of yours and a "generalizing" it https://github.com/ReproNim/reproshell project. WDYT -- should we keep it open? I worry abit about adding it so if we start promoting it, we would end up needing to support/extend etc and for that we better have a dedicated repo/project (like reproshell). |
|
Thanks for bringing this back up, I agree with your suggestion that reproshell is the better place to keep such a file, if my pull request at ReproNim/reproshell#3 is a good starting point we could merge that and reference reproshell here instead. |
2 participants
ref #20
This will not close the issue of changing one's
PS1, but this at least provides a template.bashrcthat others can use that implements some of the tricks and "best practices" mentioned in the shell-basics section.I've tested
source .repronim.bashrcon ubuntu,git-bashon windows, and the built-inubuntu bashon windows, and played with the basic functionality and they appear to work on those environments.Feedback on making a better
.bashrcwill be much appreciated!