Feature idea: Taggable environments to group shell commands

[tofagerl]

I realize the headline doesn’t make sense sense, so I’ll try to explain it:
I use different commands in different environments. For example, we have some Java projects, some Node projects, and some poor godforsaken projects that use both.
When I’m in a Java project, I don’t need to see all the node commands, and vice versa.
It would be great if we could use some sort of local .atuinrc file to tag an environment so that we could include those tags in the commands that are saved on the server; that way we could ignore the tags we don’t want, or configure some tags commands to never be included in the Atuin output unless we’re specifically in an environment that uses that same tag.

Example tags:

• Linux
• Macos
• Work
• Nix
• Node
• Java
• Rust
• JDK:17
• JDK:21
• JDK:8
• npm
• yarn
• Shell:Fish
• OS:Macos
• Project:Wombat
  And perhaps !Java or something to denote that Atuin should specifically not list commands that include the Java tag.
  etc.

And yes, this is a superuser/advanced feature that shouldn’t be necessary for 95% of the users, since the searching already fixes most of this problem, and it’s not really worth the effort for most.
It just bugs me personally

[Adda]

I would say this idea is related to

Different databases for different shells?

All, I am very new to Atiun, just installed it last week. I’m liking it so far, but I have what is probably a dumb question: is there a way to have different databases for different shells? I only ask because I’m also fiddling around with nushell and its syntax is quite different from zsh/bash. Those two are close enough that most zsh commands would do okay in bash. But this: ls | where type == file | sort-by size | reverse just sort of has zsh say “what?”. So I was wondering if there is a …

The env variables discussed there would work the same as the tags requested here.

I like the idea of .atuinrc (in a project root) where one could specify multiple default filters (tags, env vars, possibly even search modes etc.) for the whole project directory structure.

Alternatively, the tags / end vars could be specified dynamically by an Atuin-specific env var (instead of a rc file) which could be loaded with something as

direnv – unclutter your .profile

upon entering the project.

[ellie]

@tofagerl

some poor godforsaken projects that use both

Sounds good! Like @Adda said, this is similar to the other issue.

I’ve been wondering if a project-specific Atuin config file might be a nicer way to handle workspaces. That way, we can track workspaces when they move to new locations, tag them like you say, and give them other project-specific Atuin config.

I’d definitely prefer the config file over some env vars though.

Would it also be good to get some sort of TUI/CLI support for this too?

[tofagerl]

I leave all implementation details to those better equipped to deal with them
I do enterprise backends, this way beyond my skillset

[Adda]

@ellie

I’d definitely prefer the config file over some env vars though.

Agreed. The env vars approach is a nice and flexible idea, but the rc file is a more approachable and, more importantly, well-defined (as in confined in clearer boundaries) solution, I think.

How would this work if the rc file is in the project’s root and the user is in any subfolder in the project? Would it be enough for Atuin to always search for any rc file in the hierarchy of the parent folders up to the filesystem root, parse and load the configuration within for each run of Atuin? Parsing is slow…

Further improvement:
Presumably, a hierarchy of configuration files could be constructed, from the filesystem root to the current folder, combining the configurations along the way. Something like projects/.atuinrc (setting filter mode workspace) and rust_project1/.atuinrc (setting tag rust_commands). It might be useful, but it is more difficult to with possibly low gain to the majority of the users.

@ellie

Would it also be good to get some sort of TUI/CLI support for this too?

For me to find it useful, I would definitely need to be able to override the predefined filters and tags once within the TUI, similarly to how the default filter mode is set now and can be changed directly from the TUI. To set specific tags, maybe have sort of a tag picker with the option to remove (some of) the currently set tags and set other tags for the current search.

This all sounds amazing to me in theory, but as already pointed out, the group of users that would potentially find it useful and actively use it may be small. Yet the work to be done is not insignificant. Perhaps, the simplest MVP with a single rc file in the current folder with the predefined tags (which can be removed for a broader search from the TUI) would be actually useful to more users.

I personally do not see much reason for adding support from the command line, as I presume most users run Atuin with up arrow or Ctrl-r shortcut, not by running Atuin manually with a command. What kind of use cases would you imagine for a CLI support? It sounds logical to me to add CLI support if the functionality is already there – then one could create aliases for various Atuin configurations, one for general search, one default for the current environment search etc.

@ellie

I’ve been wondering if a project-specific Atuin config file might be a nicer way to handle workspaces. That way, we can track workspaces when they move to new locations, tag them like you say, and give them other project-specific Atuin config.

It makes sense to me. But I must say that it is really convenient and pleasant to work with the automated workspace “creation” (without having to create an rc file).

[AtomicRobotMan0101]

This reminds me of a tool I use already: SyncThing.

In the various directories I wish sync’d are two folders, .stfolder and .stversions

Both are hidden dotfiles. The .stfolder is empty, but its purpose is simple: its presence is a visual indicator that this folder “root” is indeed sync’d.

Perhaps, another idea?..

What about users typing atuin profile name

It would then use and store all commands thereafter with the profileName. It can be completely arbitrary and self-filtering within that profile when called?

Management is simple:

• atuin profile list … lists all profiles available
• atuin profile default … drops user back to the default all profile (our beloved atuin as-is)
• atuin profile delete name … (also deletes commands used in that profile)
• atuin profile collapse name … (deletes profile name, plus dumps all commands into default)
• atuin profile foo … creates foo and user is now using foo list

when a user ctrl-r (I map ctrl-upArrow!) the prompt will show the user is using foo (at the moment it says GLOBAL (IDKWTM)… but change to PROFILE: FOO) (??)

Some random brain farts:

• by using atuin profile foo it will be in the default atuin history, therefore fast to find if one uses many profiles
• it isn’t dependant on a directory structure or dotfiles, or directory traversal down to root looking for one
• I can have n-terminals open with different profiles in each
• I use Gnome shell with and without fish. Perhaps the shell can be opened and the command issued just the same fish && atuin profile foo

[Adda]

This approach does have some appeal. It would be simple and easily scriptable (using direnv, you could set it that the corresponding profile is enabled each time you enter the project and any directory inside it).

The problem I personally would have with this approach is that profiles are something inherently separate. You do not expect to be able to search within “multiple profiles” simultaneously, as opposed to searching within multiple tags (multiple tag-corresponding command groups) simultaneously. I think that being able to specify multiple tags is the ultimate goal of the discussed feature. Otherwise, we could really only create very general profiles such as “programming”, “sysadmin”, and “fun”, for example, but nothing more fine-grained. One needs git commands in all projects, be it Rust, C++, or Python (the suggested tags mentioned above). Therefore, you would either have to constantly switch between profiles when inside a single project, or you would just have the aforementioned generic profiles for ease of searching.

Profiles sound great in general (as another feature), I think. In this case, however, I believe they do not satisfy all the use cases discussed in this thread (which admittedly might be of interest to only a small group of users).

The same approach could be applied to tags, however (where I would not have a problem with the semantics of searching within multiple tags):

• atuin tags list: List all currently set tags.
• atuin tags add tag [TAG...]: Set listed tags.
• atuin tags remove TAG [TAG...]: Unset listed tags.
• atuin tags clear: Unset all tags = search the whole database.
• atuin tags default: Set the default tags specified in the Atuin config file ~/.config/atuin/config.toml.
• atuin tags create TAGNAME: Create a new tag TAGNAME.
• atuin tags delete TAGNAME: Delete tag TAGNAME.
• …

Hmm, all interesting ideas indeed.

[tofagerl]

Loving all of this “yes and”

[Adda]

Well… Exactly Brainstorming and all. From my point of view, it is always better to have as many ideas and suggestions as possible. One can then sift through them and decide which to act upon and which are not all that useful.

[tpoliaw]

My two pence worth

@ellie

That way, we can track workspaces when they move to new locations, tag them like you say, and give them other project-specific Atuin config

This would be incredibly useful. To have the same projects checked out in different directories on different machines (or even in multiple directories on one machine) and have the history shared between them would be great.

It might be a bit of a niche use case but filtering by subdirectory of a project would be useful. Things like mvn -f ../another_directory ... being recommended only when you’re in the right directory for the relative path ../another_directory to make sense would be a godsend.

@ellie

Would it also be good to get some sort of TUI/CLI support for this too?

A CLI method to list the currently effective configuration and where it came from would be useful for debugging things - similar to #1542.

@Adda

Parsing is slow…

I don’t think it would be too slow. Things like git/ripgrep/fd do it for ignore files and the data being parsed isn’t too complex.

@AtomicRobotMan0101

What about users typing atuin profile name

@Adda

atuin tags add tag

I like the idea of tags more than profiles but with fuzzy searching I’m not sure how much use filtering by tags in the tui would give. Would a command in one rust project be relevant to another project (beyond things like cargo run which would be in the local project history already)?

Another thing to think about would be whether there is any state shared from one execution of atuin and the next that could be used to store the active profiles/tags? As far as I’m aware, one process can’t set environment variables for its parent process (or future children of the parent process). Maybe a file in $XDG_RUNTIME_DIR by session_id could work?

---

I’ve just re-read this

@tofagerl

that way we could ignore the tags we don’t want, or configure some tags commands to never be included in the Atuin output unless we’re specifically in an environment that uses that same tag.

and the idea of filtering out the commands that are never going to be relevant is one I can really see the benefit of.

[tofagerl]

Perhaps with an escape key in the Atuin interface to “remove all filters and show everything”?