-1

I'm currently hosting a Github project that modifies the ~/.bashrc file. With the project being continuously updated, I'll need to know how to update the ~/.bashrc file without completely breaking it. As common courtesy and to prevent confusion, the changes I made start with 

########## Added by Bash-Shortcuts ##########

and end with

######### End. https://github.com/OoLunar/Bash-Shortcuts/ ##########

Not quite sure how to go upon this, ideas?

EDIT: I ended up using @reichhart's answer, and added the line:

test -r ~/.Bash-Shortcuts/.commandsrc && . ~/.Bash-Shortcuts/.commandsrc

This solved my problem perfectly.

Lunar
  • 480
  • 4
  • 11
  • 1
    Not a direct answer to the question, but why not use `source` to add new commands to your .bashrc file? – eduffy Apr 22 '19 at 15:17
  • I didn't even know about that. I honestly thought that source was just a thing to reload the config to system... I'll look into further detail. – Lunar Apr 22 '19 at 15:17
  • Take a look at `sed`. – Cyrus Apr 22 '19 at 15:23
  • 1
    See: [Replace text between two lines with contents of a file stored in a variable in sed](https://stackoverflow.com/q/46574862/3776858) – Cyrus Apr 22 '19 at 15:26
  • @reichhart, Is it possible to reference another config through .bashrc? I am adding commands for the user to use, not editing .bashrc for some other means. – Lunar Apr 22 '19 at 15:31
  • That's what @eduffy meant by `source` or `.`. You can simply put a line in the `.bashrc` like e.g. `. /home/user/.myapplicationrc`. Simply a dot (or `source`) then a space and the file name. I used here absolute filename because it _could_ be that `/home/user` is _not_ the working directory. – reichhart Apr 22 '19 at 15:35
  • Ahhh, alright. So you're saying, instead of putting the functions and aliases directly into .bashrc, I could reference them by putting the line `./etrc/bash-shortcuts.d/` into .bashrc, which would prevent the bashrc from being broken. – Lunar Apr 22 '19 at 15:38
  • No, `/etc/xxxx.d` dirs were just examples to explain the solution approach. If your application is running as user `user123` and the user `user123` should be able to modify it then the file should be located in `/home/user123` (or `/Users/user123` on macOS). Don't put it somewhere below `/etc`. If this would be a solution for you then rephrase your question and I will give an answer with description for also detecting already included file. – reichhart Apr 22 '19 at 15:43

1 Answers1

2

Solution approach: sed or other inplace processes

Possible issue here: The process modifying .bashrc can crash and then the .bashrc could be broken.

Better solution approach: source an external file.

Assuming: Application is called myapplication and it runs as user user123. The home directories are below /home like on e.g. Linux (macOS: /Users).

  1. Create file ~user123/.myapplicationrc (resolves to /home/user123/.myapplicationrc). Put all commands/configs for Application here. Make it at least readable for user123 (execution bit is NOT required).
  2. Add this line to ~user123/.bashrc (is /home/user123/.bashrc) -- best at the end of the file: test -r ~/.myapplicationrc && . ~/.myapplicationrc (A dot, a space and then the file name.)
  3. Optionally: On your install code make a check if the line does already exist in .bashrc and add it if misssing: fgrep -q .myapplicationrc ~user123/.bashrc || echo 'test -r ~/.myapplicationrc && . ~/.myapplicationrc' >>~user123/.bashrc

More details: Replacement for source in sh

EDIT: Use ~ instead of /home/.... This "tilde expansion" does not work in older Bourne or Heirloom Shells. But all modern Shells including small shells like e.g. Almquist Shell support it. On macOS it also works fine but resolves to /Users/....

reichhart
  • 813
  • 7
  • 13
  • 1
    In step 2, I'd recommend using `[ -e "$HOME/.myapplicationrc" ] && . "$HOME/.myapplicationrc"` -- that way it doesn't have a hardcoded path, and it'll fail cleanly if someone deletes there . myapplicationrc file. – Gordon Davisson Apr 22 '19 at 18:47
  • It was intended to _NOT_ use `PATH` or `HOME` as dependency because I don't know _anything_ about the application. On some servers I have hands on there are e.g. applications with reduced environment (e.g. `env -i`). But I will take your proposal and I'll add `test -r` as check. Upvoted your comment. Thanks. – reichhart Apr 22 '19 at 19:28
  • 2
    @reichhart Hmm, I have the complementary worry that files (and home directories) get moved around and renamed, and like to write things so they're robust against *that*. How about a compromise: bash (but not all other shells) will expand `~` to the home path even if `$HOME` isn't defined (try `env -i bash -c 'echo ~'`), so `test -r ~/. myapplicationrc && . ~/myapplicationrc` should work in both situations. – Gordon Davisson Apr 22 '19 at 21:02