Atuin turns shell history into a database allowing one to sync, search and backup it up.
The snap atuin (which is currently private) need access to existing shell history files for the user to (explicitly) import it. For that reason the snap declares several plugs as ‘interface: personal-files’ to access various shell history files.
I’d thus like to request for those interfaces to be approved.
Thanks.
Hey @artivis ,
I am +1 for use of personal-files with read access to various shell history files. But since atuin is not the clear owner of such directories I prefer the user to grant the manual auto-connection instead if they are willing to do so (you did not request this but I am mentioning it just in case it is expected). Can other @reviewers please vote?
Also, can you please list in the snap description which files atuin is willing to get access? I think it would be useful for users.
Thanks!
Thanks for the review @emitorino,
I agree with you regarding the manual connection of those interfaces 
.
This snap is still somewhat under development, there are still a couple things to improve, that’s why it is still private. Once done, and prior to making it public, I’ll give it a proper description and everything necessary.
Thanks.
I am so excited for this, @artivis !
I use Atuin everywhere, and they’re all a mish-mash of versions - and I don’t mind saying, I have no idea how to update them. I’ll certainly be a guinea pig if you need someone to test the snap 
Well, if you can’t wait, you can find the snapcraft.yaml on my repo 
Mind that I only focus / tested Bash so far as it is the shell I use.
The snap comes with ble/bash-preexec loaded but they still have to be sourced by the user (e.g. source /snap/atuin/current/usr/share/bash-preexec.sh). On the bright side, auto-completion should work out of the box.
+1 from me as well for the use of personal-files interface with read access to the files below.
$HOME/.bash_history$HOME/.local/share/fish/fish_history$HOME/.local/share/resh/history.reshjson$HOME/.zsh_historyI’m happy with the auto-connect, in case the description of the snap clearly states this. Thanks.
The snap summary says: “Magical shell history” and talks about replacing your existing shell history with an sqlite database - but it doesn’t clearly specify that it will read you existing files. Also from what I can see, atuin only tries to access this when specified by the user via the import command https://docs.atuin.sh/reference/import/. I wonder then if you could add a simple command-chain wrapper script that when it sees it is being invoked with the import command, first checks whether any of these plugs are connected via snapctl is-connected - snapctl is-connected dot-bash-history - and if not, suggests to the user that they need to connect these for it to work. Given the snap is for the shell, I don’t think this should be too onerous to expect of users, and it would allow them to make an informed decision as well in that case.
something like the following perhaps:
#!/bin/bash
if [ $# -eq 2 ] && [ $1 == "sync" ]; then
if ! snapctl is-connected dot-bash-history && \
! snapctl is-connected dot-fish-history && \
! snapctl is-connected dot-resh-history && \
! snapctl is-connected dot-zsh-history; then
echo "Error: Requested to sync existing history but no interface connected which would allow this."
echo "Please connect the respective interface such as: sudo snap connect $SNAP_NAME:dot-bash-history"
echo "and try again."
echo "To see which interfaces are available and whether they are connected:"
echo "snap connections $SNAP_NAME"
exit 1
fi
fi
exec "$SNAP/atuin "$@"
As such, for now, +1 from me for use of but not auto-connect of these plugs - can you please update the snap description to have it mention that you can import your existing shell history into atuin and try the wrapper script idea?
Hmm although using bash to implement the wrapper script may break the existing auto-detection of the shell when using import auto - but it would be interesting to see if this does work or not.
Thanks for the suggestion @alexmurray, that would be a nice usability improvement!
I’ll tinker with this idea .
Hello,
Is there anything else for me to do here?
Hey @artivis , did you have a chance to look into the changes that @alexmurray has mentioned, particularly the one regarding the snap description?
Once the changes into the snap description are made, I’ll proceed with granting the request as per the votes. Thanks.
Thanks @sahnaseredini for your reply.
As per a previous comment of mine, I’m still working on the snap and need these interfaces for testing prior to any public release. It will thus remain private for now. Once done, I’ll update the description properly. Similarly, I need those interfaces to iterate over Alex’s suggestion for the command-chain script.
This is probably worth a separate post but, how is one expected to develop and iterate a snap which functionality depends on super privileged interfaces ? Is there a way to forcefully connect them locally without a prior store-request?
First of all you do not need to make the snap private unless you have any super secret code in there… instead you should simply mark it as “unlisted” … that way it will not show up in any searches and only people that have the actual link to the snap or that you have given the snap name for test installs will be able to use it.
To try out interfaces locally, you can always install a local snap with the --dangerous flag to the snap install command and then use the snap connect command to connect the interfaces manually
A bit of a side question, but I’m curious: does this snap provide the atuin client, or does it support running an atuin server as well? I’ve been very interested in atuin but would like to self-host the server, and would much prefer a snap to either directly running/managing/updating a binary or docker container.
Thanks for your work on this!
To try out interfaces locally …
Right, thanks . Is that true for all interfaces? I have a vague memory of not being able to connect something without requesting it first. It might only have been a bad dream tho.
does this snap provide the atuin client, or does it support running an atuin server as well?
The snap ships the whole of atuin meaning both client and server.
Altho, in server mode it seem that one has to provide the database separately (doc). I successfully tested that, pointing to a postgres Docker instance.
@sahnaseredini Alright, I’ll try to wrap this snap up over the weekend .
I was considering trying my hand at creating an atuin-server snap which would bundle the database as well, since that’s the part of running the server that appears (to me, a thus far non-user) to be non-trivial. I think snap install atuin-server configuring everything including the database would be hugely beneficial, in the same way that the nextcloud snap feels like magic compared to the lengthy manual install process. Then again, I haven’t created a proper snap before, nor tried to set up an atuin server, so perhaps this is either difficult or unnecessary. I would just prefer if the atuin snap didn’t require a database to be previously installed (and configured?) on the host system, and bundled it instead.
What do you think of this? Would this be within the scope of your atuin snap, or would it be a better fit for a dedicated atuin-server snap?
Oh I see, I get your point. Well I guess I could give it a look but no promises
Hello there,
I’ve updated the snap description mentioning the interfaces to connect and I’ve also added the ‘command-chain’ script suggested by @alexmurray .
@oac I had a quick look at integrating a database to the snap. I’m not familiar with the topic and I don’t feel confident enough to do a good integration job there at the moment. I’ll leave this to future contributions. I’ll try however to write a short blog post on spinning up the server locally if it helps.