I need to complete the OS detection in dotfiles first, and then install tools, probably very similarly to ubuntu init

90_session_record.sh
TODO: include date/time in output of __list_avail_sessions?

When I forked from asharpe, the super-duper prompt from Cowboy has been munged. I tried to bring back some of it, but it's basically screwed. jloh's fork has a working prompt.

When cloning to Raspbian Squeeze, Git complains of this setting:

[push]
	default = simple

The simple option is default in Git 2.0. Probably it's unknown to older Git on Raspbian. Might want to make it upstream since my workflow is compatible anyway.

They would probably help with the refactoring I'm attempting to do on Issue #23 and Issue #24.

BUT

I don't wish to place this as a requirement on the 1.0 milestone (for macOS): I just want to get on with "finishing" dotfiles so that I can begin to port / update it for Linux, especially SUSE.

There's an xUnit test framework for bash called shUnit

The code is at kward/shunit2

I'm not sure yet if this is a bug, or an issue with the way Raspbian Desktop has been built.

The method I'm using seemed to work when I played on my earlier Raspbian on an actual Pi, but on the Raspbian Desktop running in a VM, the /etc/os-release contains no mention of "Raspbian", only "Debian".

I'd like to be able to determine Raspbian, not just assume that it must be Raspbian if it's Debian.

This is kind of a blocker for addressing other issues in Raspbian.

There's an old ansible ubuntu role from Cowboy that I didn't look at much because, well ubuntu, and also it does things that may be useful in vagrant or something, but not generally for me.

but.

I think it would be nice to move away from Cowboy's bash-scripts to install brew recipies and instead use something like brew bundles.

I could use this as a launch pad into doing similar tasks for the other target systems that I have #8, #9, #10, and possibly #12

• add anaconda to 30_osx_homebrew_casks.sh
• make a function to activate/deactivate anaconda (my existing one doesn't work), buy path_add or path_remove ~/anaconda3/bin

basically: anaconda is a really good distribution for Scientific Computing with iPython/Matplotlib/numpy etc. and setting all this up in MacOS on vanilla iPython is a pain.

Could maybe consider an installer for anaconda on Linux, if I like/want it there, that's an optional thing to consider with issue #8

The python init attempts to install some python modules using pip, but into the global context.

• do I actually want to do things this way? If so which is better, pip or the OS's package system?
• Perhaps I don't want to init anything beyond virtualenv (and maybe virtualenv wrapper used by eshell-prompt-extras)?

I need to complete moving all the comments into $FUNCDESC variables.

The main motivation for this is so that I can tell from a simple whence funcname how to use the function (since type -a prints the actual definition, and a comment in $FUNCDESC will be part of that).

If possible I would also like to mimmic emacs' "defined in blah.el" so I can quickly locate the code in the dotfiles tree. Not sure if/how that can be done

I'd like to adopt a "self-documenting" style for my Bash functions, much like Emacs/Python functions with docstrings. I already worked out a nice way to do that in my python source script, but it will need to go into bin/dotfiles to be able to use it across the whole project.

• error and usage functions from source/50_python.sh
• path manip functions from source/99_path.sh
• check for more, maybe in source/50_misc.sh? or source/90_work.sh?

source/20_prompt.sh

function __prompt_sizes() {
#TODO: formatting/colouring and testing.

function __prompt_cpu(){
#TODO: these are for Linux only
⋮
#TODO: and surely this date manipulation can be done by an existing tool,
# rather than this hand-crufted mess?

/home/mjl/.tmux.conf:22: invalid option: mouse-select-pane
/home/mjl/.tmux.conf:26: invalid option: mode-mouse

And then tmux locks up. Have to Ctl-A D to get out.

Work-around for now: temporarily disable ControlMaster

The log file continues to stream after the function "kills" the SSH process, because it's actually coming through the master.

Because_ the awk scripts in __prompt_cpu() naively print fields by position, when the uptime goes past 23:59 mins and uptime prints "X day, Y mins" then everything gets out of position.

• Issue #20 is about replacing the os provisioning mechanisms in Dotfiles with Ansible playbooks

• This morning I was reading The Book of Secret Knowledge and discovered and read about Bash-It which is a Bash framework (which has a demo Docker that also bundles a test suite)

• Issue #28 is about needing tests - for which bats seems pretty good.

• issue #49 is discussing virtualenv vs venv, and with the retirement of Python2 this might now become more pressing.

What I'm discovering is that this project might be headed towards the same kind of refactor / move that I undertook in 2016 for Emacs -> Spacemacs.

I need to consider where I am with this, and which directions I need to go.

Clearly there is value in separating my "dotfiles" configurations (especially the bash and python things) out from the mechanics of provisioning them into a new machine. Although I think that what I might end up with is probably going to involve Ansible as well as the mechanics of the "Link step" in Dotfiles, with other things like this being in separate repos:

• Installing bash-it and customisations (maybe this is where the stuff in /source belongs?)
• Spacemacs and customisations (already separate)
• Python and customisations
• Node.js and customisations
• (future-thing and customisations -- e.g. Vagrant / Docker / Ruby / Whatver...)

There is clearly a pattern here, and maybe it's worth looking to see what is generic about these language environment stuff.

Should it all be pulled apart and then glued back together under my abandoned Origin project?

According to this Stack Overflow question I should be using ssh -O exit <hostname> to request the master to exit, instead of removing the control file.

I need to do these things:

• Make a Wiki for this Project
• Move Cowboy's original README to the Wiki and replace with my own, more specific README
• Probably a history page in the Wiki and/or relationships with other cowboy/dotfiles forks (fellow Squizzers asharpe and jloh)
• Document my own things, of course.
• Exploratory notes. This category might better go in my blog.

grep: warning: GREP_OPTIONS is deprecated; please use an alias or script

This occurs whenever grep us run, and when the shell first starts.

• I used to do extensive configuration for Cygwin/Emacs
• Windows 10 has the WSL which is Ubuntu on Windows (with native ELF64 support), finally making Windows+WSL an actual Unix/POSIX/Linux system.

I'm unsure if this really belongs with dotfiles. Probably supporting the WSL is straight forward (like Brew/Ubuntu), but Cygwin could be quite a handful.

In particular:

• vagrant boxes should live in ~/vms/boxes in my directory structure
• rbenv runtimes (indeed all runtimes) should live under ~/lib -- ie.e ~/lib/rbenv

Take a look at how the stuff from vendor is initialised...

Just need to re-arrange some pages, update sections for issues that have actually been resolved.

I'd like to make periodic pop-up mindfulness prompt texts to bring my focus back to what I should be doing and how I should be thinking. This is to combat procrastination and funking out at work.
Some examples

• Just Do It
• Stay calm
• what's next?

and so on. I had some better ones which have left my head, I'll add them to this issue as a list for requirements.

I think Hammerspoon has a way to periodically do tasks, and to display messages from out of a Lua array or something.

e.g. LightTable tries to run /bin/sh when starts a subshell. So Bash honours POSIX and fails on 30_file.sh where a function is defined with '-' in its name.

I think for sub-shells I probably don't want all the interactive dotfile guff anyway. So I should probably try and detect if bash is running as /bin/sh or POSIX and skip sourcing all the stuff.

just because it'd be cute!

in suse, this doesn't exist.

[mjl@tesla:/run/media/mjl/MARBIG32/mike/x]
[06:58]$ echo $MANPATH
/usr/local/man:/usr/share/man

Probably want to link it to the first local OR

1. make a ${HOME}/man
2. add to $MANPATH
3. link into there

It shouldn't be picking ubuntu on a SUSE machine; that should only be chosen on ubuntu.

Run the following init scripts?
 ✖  10_osx_xcode.sh
 ✖  20_osx_homebrew.sh
 ✔  20_ubuntu_apt.sh
 ✖  30_osx_homebrew_casks.sh
 ✖  30_osx_homebrew_recipes.sh
 ✔  50_fonts.sh
 ✖  50_node.bug
 ✔  50_python.sh
 ✔  50_vagrant.sh
To edit this list, press any key within 8 seconds.

Either the logic to deselect it is flawed, or the logic to detect ubuntu gets a false positive when on SUSE (tumbleweed)

Should be something like the following

• a configuration for dotfiles that tells it where the private secrets are and how to retrieve
• a step to retrieve the private files (git sub module, or download a gpg-encrypted file from cloud storage or link to local Dropbox/grid mirror etc.)
• then copy it into ~/

stick this in link/.bashrc

Bash's source is like BASIC load or IPython %load. I don't know why they called it source to be honest, and I keep wanting to load things.

I probably want to remove it. I should review it first just in case there's anything that might make vim less horrid to use, though I doubt it.

What actually does all that stuff do to vim?

need to install mu --with-emacs to have the emacs library.

The numbers in the source/ directory dictate loading order, which is okay. But I've grouped them wrong. They should be ordered not only by when they get sourced, but also by loose functional element.

So a new grouping:

00: dotfiles itself
10: unassigned
20: shell environment controlls
30: tools and utilities
40: operating systems
50: development environments
60: unassigned
70: unassigned
80: host-specific
90: applications
99: loaded last: clean-up of the rest (e.g. shell path goes here)

Within the groups I can still order things by using the 2nd digit, if it's required.

I need to rethink how this works, because when I did a fresh install of SUSE and then dotfiles, it broke all the things.

Workaround: recover the original ~/.config from the backup that dotfiles makes, and then manually link in the midnight commander stuff.

I want to fold in the bootstrap from hax-vm so that it sets up my environment for SUSE, similar to Cowboy's ubuntu init

I don't know if Ansible is a solution I want to use, or continue to roll-my-own like with hax-vm

I'm sure that all of the stuff Sharpie does makes sense, but there are a few surprises that are tripping me. So far

• ssh is a function. What actually does it do?
• what's all the Ruby shimm's about?
• there is stuff for Vagrant that I don't understand

All of this should be documented in this Project's Wiki.

80_work.sh

#TODO: review this file -- it is specific for Squiz, and these ipowered hosts

are all due to be decommissioned One Day, making this obsolete.

I'm discovering as I play with Jupyter & matplotlib on a macOS machine, that virtualenv is suboptimal, because it copies Python binaries, which then are no longer macOS Frameworks, and so matplotlib doesn't work when called from inside another application such as a jupyter-enabled virtualenv.

Also tools like MS-VS Code seem to advocate the Python standard virtual environment system (since 3.6) of venv.

Also, I've been using "venv" in my bash fns as a short-hand for "virtualenv" (much like pipenv does, apparently) and so that'll be a bit confusing.

I need to rethink how / if my mkvenv, lsvenv, rmvenv fns work with virtualenv and venv; maybe switch them to venv and refactor the virtualenv-aware fns to mkpyv or something?

See:

• Difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper (Stack Overflow)
• Python virtual environments - a primer (realpython.com)
• venv - Creation of virtual environments (Python docs)
• pipenv (github), which uses virtualenv, that may or may not be a problem ?
• Pipenv and virtual environments (Python-Guide.org)

Need to move is_exe function from bin/dotfiles into source/10_meta.sh. Might have to replace its use in the Init step with raw calls to type/test for executables.

Need to think about the $LIB variable

Then need to document/discus how one would share any file in source/* so long as you also share the meta

A large percentage of this repo is either

• broken (#14, #19), or
• not in use by me (#6, #13)

These issues are also not that high on my priorities to fix, yet I may want the code someday when or if I start to get into those technologies. I don't want to loose the code that's doing these things, but I also don't want it hanging around in my day-to-day dotfiles cluttering them and/or causing issues.

So I should probably make a branch and keep that "for later", then delete the crud from the master.

i think. i still can't git.

There's heaps of goodness from jloh's fork that I should look at and cherry-pick out.

Also asharpe's fork has some fixes and improvements since I forked from him. Notably fixing sensitive details, but heaps of other commits...

This is a great way for me to learn:

• using multiple Git Remotes
• Cherry-Picking across Remotes

I very much like the lambda in eshell, instead of a dollar-sign:

~/Work/svn/puppet λ 

It would be nice to have something like this in bash too. Perhaps alpha or beta for normal and continuing prompts, and omega for root?

[mjl@milo:~]
[16:49]α sudo \
β bash
Password:
[root@milo:~]
[16:49]Ω

there is still some goodness left in my dotfiles-old repo from about 10 years ago that would be great to retrieve

• zless/gzless/pkzless etc
• editor lister functions
• "emacs" wrapper for emacsclient
• backup function, date function and other things

I need to finish going through my old stuff and bring in what I would like to keep, some these are gems.

also I need to think about source/50_misc.sh -- is it about bash misc config, or is it a catch-all for unsorted functionality? It would be better to sort that functionality

I only use RedHat vms when hacking work stuff, so this may be a lot simpler than issue #8 (SUSE).

There are two flavours of RedHat-derrived OSes

• RH6 (uses yum and system V init)
• RH7 (uses dnf and systemd)

I already added new OS detection logic to dotfiles in commit ed5b5f4

31_ssh.sh

• TODO: regex for IP address
• TODO: _ssh-add shell completion
• TODO: ssh-proxy doesn't work

Naming conventions

Functions and variables should have the following naming conventions applied consistently in dotfiles

See the wiki page for the details.

While that page may change a bit, this issue can be closed for purposes of the 1.0-macOS Milestone once the code is meeting the guidelines I've compiled when I close the issue.

about 200MB. I understand why (it's a whole Ruby virtual env and library), but

• I don't Ruby, only incidentally through this script and some other tools
• maybe this belongs in ~/lib? (issue #6)
• maybe it only installs in an init step which I could just disable? (I should consider this similar to python, issue #7)

Need to work out the answers to these before deciding what course to take.

actually they're a real mess. I think eventually they should all be folded into places that make sense (see issue #2). for now I've renamed sharpie's files so to assist with the review, but I want to be rid of them.

I should put my normal source header on any that i keep too (to make identifying cowboy vs. mine easier, which assists me an answering the question "where did this crud come from, and is it something I care about?").

The function keyword should be similar to the alias keyword and list functions. But it doesn't.

I would like a functions or similar that can list the declared functions, excluding those beginning with an underscore (perhaps a switch --all to include those).

Something based around something like declare -F|awk '!/declare -f _/{print $3}'

or just declare -F|awk '{print $3}' for --all functions