Bash scripts?

Yeah

You use Vim as your main editor, right?

You can have ShellCheck check your code as you're typing it in Vim. github.com/koalaman/shellcheck#in-your-editor

@EliahKagan oooh neat

You can also run it on the command line or paste (or type) code into the website.

I do about half my text editing in Vim but I don't have ShellCheck or any other plugins set up in it.

I use ShellCheck integration in VSCode, though.

I have been playing around with mc as a way to move my files

It works really nicely

but I haven't found a way to do it without entering each directory and selecting the files there

that works for my task

I have about 15 directories each with 10-40 files

so changing directory is fine

and even kind of preferable to selecting from a complete tree like in Caja

because I'm a bit more likely to be able to check easily before making a mistake

still, it would be better if I could work out how to see the whole tree

and select from it

@Zanna So it lets you browse directories in the tree view, but it doesn't show the files in the tree as well, which is what prevents you from doing that?

yes

@Zanna I don't know, but you seem to be saying that having APT remove itself is not reversible. Challenge accepted.

oh haha I am not saying it's impossible

but it's not reversible by running the converse of the command

like, I can't run sudo apt remove apt && sudo apt install apt

Yes, I know. :)

I'm not seriously suggesting there was anything wrong with your characterization of that situation.

@EliahKagan sorry haha I mean that's what I meant in my comment

@EliahKagan we do have some Q&A about how to reinstall APT I think

@Zanna For it to be truly sporting, dpkg should also be removed.

I don't remember how to fix that

was it perl being removed that made the system totally unrecoverable? I suspect it was...

@Zanna Let's see...

Which package management utilities use perl?

unrelated to everything: I love the Biology Stack Exchange and the cool questions like this one that come up there

I think dpkg uses perl

That is interesting.

dpkg-dev depends on perl.

@Zanna Some builds of BusyBox, I believe including those in all recent releases of Debian and Ubuntu, have a dpkg command. /bin/busybox in these systems is statically linked, so the absence of most other stuff won't keep it from running, and it could even be manually extracted from a .deb and copied to /bin.

I have not used busybox dpkg and I've been meaning to try it out at some point. I learned about it from muru. Once the dpkg and apt packages and their dependencies are installed from manually downloaded .deb files, fixing the system shouldn't be too hard.

@EliahKagan But I don't think dpkg-dev is needed for any package management operations other than making packages.

ek@Gnar:~$ aptitude why dpkg-dev
i   build-essential Depends dpkg-dev (>= 1.17.11)

← 19 messages moved from Raiders of the Lost Downboat

@EliahKagan yeah...

@EliahKagan oooh :)

@Zanna Do you use any plugins in Vim? I actually do not, and I've been meaning to set that up.

No I don't

I keep meaning to try to do interesting things like that

But I usually only write stuff like notes on reading and recipes and small shell scripts. So I feel I am not really the target audience

I'm an imposter in vim :)

Sounds like vimposter syndrome to me.

I mainly write my stuff in "plain text" just to save disk space and other system resources and because I find some of the line editing and moving tools handier than clicking around

@EliahKagan hahaha:)

What is it that you're saying you're not the target audience for? Vim plugins?

Yes

Well, as you know, even very short shell scripts can be extremely bad and thus benefit from static analysis. :)

Wow, that did not come across as encouraging. :)

Also, I don't think all Vim plugins are related to software development.

Like, I think there are spell checkers (I'd forgotten about that but my misspelling reminded me) and Markdown linters.

@EliahKagan hahaha that script XD

Yeah. I should really try to explore!

Though your mentioning how you mostly use plaintext makes me think of something else.

Source control is traditionally used for source code, hence the term, but it's useful in general for plaintext documents.

Yes

I should implement that

Definitely

You can check binaries into source control but you're not usually going to benefit as much, e.g., from diffs. And the repository might grow faster than you'd like.

Though I think some people have implemented smart diffs for image types like PNG.

That sounds really difficult to do

Yeah. I'll try to remember to see if I can find some details about it.

@Zanna Are you at / with access to your computer?

Also, have you used source control in any capacity before?

@EliahKagan hmm? Not right now

Okay.

(I was so excited.)

@EliahKagan no, I mean a friend showed me how to do a couple of things but I didn't use that, so I forgot it

@EliahKagan haha it takes my laptop about 9 seconds to boot

That's... not slow.

done :)

Do you know what source control system you had tried? And if you liked it?

It was git we were learning

sure it was good

I would suggest Git. It's the most popular.

And you don't have to use separate remote repository.

Though you might want to, so if you delete the whole directory or something, you don't lose stuff.

And for being able to access stuff from different machines.

Btw did you end up moving those recipe files?

This sounds like a change of subject but it sort of is not.

@EliahKagan yes, that can be useful. Actually I keep anything I care about in Dropbox even though I don't like it. Just for backup

I have not bothered to come up with a better way

@Zanna It's good to have off-site backups (and other backups).

@Zanna To move the files you were talking about in the question?

@EliahKagan no, I mean a better off-site backup solution than saving things in Dropbox

Oh. It seems fine to me. Maybe also save them in some other cloud service?

@EliahKagan no, I don't want to move them, because when I move them I'll probably stop working on ways of moving them

so when I've finished playing around with the answers I've got and mc to my satisfaction I will move them haha

You could make the entire directory tree a git repository, commit the files as they are. Then you can get them back.

I don't know how your directories are laid out... is the move a way of reclassifying the files, such that both the source and destination directories are conceptually in the same working tree? Then the whole thing might make sense as one repo, and you can actually undo and redo the move with git.

that would be great

because you can kind of see right

I want to move them, test them, edit them, then put them back where they were

I'm moving them as a kind of to do list structure haha

This thought is not about git but... Is your ultimate goal for the files to temporarily move them, work on them, then move them (with their possible modifications) back?

Because if so, then I'm wondering if you should really move them at all.

Might another approach be to make symbolic links to them in the destination directory?

Modifying the symlinks modifies their targets, but deleting them leaves their targets alone. And unlike hard links, the symlinks know their targets' names, in case you do end up wanting to rename or delete a target.

that's a good idea.

They would probably get revised a lot

lots of rewriting, deletions and renaming

and the directory structure might get changed as well

@EliahKagan it is a simple layout, and the destination is in the same tree as the sources

I think it could be useful to use git for versioning, and to be able to restore what you had before. But I wouldn't necessarily attempt to use it to undo just part of the changes you did (like undoing the move but keeping the modifications). If the source and destination trees have the same structure and the same directory names, then just moving them back with mv seems easier.

You can apply or undo just part of a commit in git. I'm not sure if I actually know an acceptable way to do it for this use case, but I think it can be done acceptable for this. But I don't think it's really necessary.

Anyway... you have a backup of the whole thing just in case, right?

I mean one that's convenient.

Generally using Git makes your data safer and not less safe... but having a readily usable backup ensures you can access data without having to figure out what happened and how to undo it.

I mean, because you're not yet comfortable with Git.

@EliahKagan yes

Cool! :)

I'm working on a copy of the whole structure for testing at the moment anyway

You can actually do that in git with branching.

Have multiple versions of everything that don't bother each other except when you want them to, I mean.

yes... very useful

clearly I should be doing it like that

Well, I don't think it's necessarily the only reasonable way.

I don't know as much about your use case as you do though.

I have a friend who claims to be lazy because he uses lots of nice clever tricks to make stuff easier and more convenient

I think that's not lazy at all

but I think I am very lazy

threevirtues.com

because I know there are better ways to do what I do but I'm too lazy to figure them out

But that's... very hard-working! :)

@EliahKagan hahaha awesome

Did you end up making a repository?

no...

@EliahKagan hahaha but not in a good way

@Zanna Do you want to?

yes, I think it would be useful in multiple ways

I mean, like, do you feel like doing that right now and, if so, do you know how and, if not, do you feel like my input?

it is actually pretty late right now

Indeed.

I do not remember how to do that

(I mean, especially where you are. :) )

any input from you would be much appreciated

:)

I can tell you but it sounds like you might want to rest or sleep, which would make great sense.

But yes, sure!

In the top-level directory whose contents you want to comprise the repository, you can run:

git init

ok

You can see the status of the repo by running

git status

at any time, from anywhere inside it.

Running git add stages files, and git commit commits what's staged.

git add takes a path operand. To stage everything from where you are down the directory tree, you can run:

git add .

But right now there's nothing.

what is the idea of staging?

Well, a commit is goes into the history of your repository. The ultimate goal of staging files is to commit them. When you stage files, you tell git which files you think you'll want to commit next. When you then commit, changes to those files (including creations, deletions, and renames, as well as content changes) go into the commit.

Also, if you modify or create a file, then stage it, then modify it some more, and then commit (without staging again), it's the staged version that is committed.

@EliahKagan yes, everything is "untracked"

There are shortcuts for staging and committing together. This is especially popular in the git support that appears in some editors, perhaps because if you need to do them separately, you still can by running git commands manually.

@Zanna So there is something in the working tree, just not staged?

Oh, right, because you made the repository in a directory that had files! :)

So, if you like, you can stage and commit everything.

I should possibly have suggested making an empty repo first just to see what it looks like, but this should be okay. Anyway, that looks like this:

ek@Gnar:~/source/repos$ mkdir tmp
ek@Gnar:~/source/repos$ cd tmp
ek@Gnar:~/source/repos/tmp$ git init
Initialized empty Git repository in /home/ek/source/repos/tmp/.git/
ek@Gnar:~/source/repos/tmp (master #)$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

You probably don't have your bash prompt set up to show you information at the git repository you're in, so you shouldn't expect to see the (master #) part.

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	BreadPancakes/
	ChutneySauceSpreadDip/
	CurryStewMain/
	DryProtein/
	NeedsWork/
	PastaNoodles/
	PieCasserole/
	RiceGrains/
	SnackyCrunchy/
	SweetStuff/
	TO-TEST/
	VegSides/
	WetDalSoup/
	basics/
	ideas/

nothing added to commit but untracked files present (use "git add" to track)

So, if you want everything to go into the repository, you can stage it all with:

git add .

done

Having staged them, you can now commit them.

The recommended way to write commit messages is to write a brief message -- people say 50 characters or fewer is usually best -- followed by details if appropriate. In your editor, the first line is the summary. Subsequent paragraphs (like, starting two newlines from the first line) are the detail message. You can leave out the detail message, which I think is sometimes reasonable, or you can include it, which is also sometimes reasonable.

People often use a message like initial commit for their initial commit in a repo, but they don't have to. When you commit for the first time ever to any repo (on your machine, in your login), git will tell you that it needs information about you -- the name and email address you want to appear on your commits -- and how to give it that information. After you do that, you can attempt to commit again and it should behave normally, opening a text editor in which you write the commit message.

The command to commit is:

git commit

It accepts options, including an -m option whose operand is the commit message to use in lieu of opening a text editor. But I suggest starting out writing them in a text editor (and perhaps usually doing so, too). In the editor, git places comments that summarize the changes of the commit for you.

What git will tell you to do for your name and email address is: git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

You can customize the editor with: git-scm.com/book/en/v2/…

When you run git commit and the editor opens, you can abort the commit by quitting the editor without ever saving.

6344 insertions

was that the number of lines in my files?

I believe so.

cool

@EliahKagan thanks for explaining this so clearly!

You're welcome!

I am pleasantly surprised that my explanations are clear. :)

@Zanna You could check by running wc -l with a recursive glob (globstar).

ek@Gnar:~/source/repos/tmp (master #)$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)
ek@Gnar:~/source/repos/tmp (master #)$ seq 1337 >leet.txt
ek@Gnar:~/source/repos/tmp (master #%)$ git add .
ek@Gnar:~/source/repos/tmp (master +)$ git commit -m 'initial commit'
[master (root-commit) 32f6c66] initial commit
 1 file changed, 1337 insertions(+)
 create mode 100644 leet.txt

@EliahKagan 22870 total

Apparently not then. :)

But you did run git add . in the top-level directory of the repository, right?

yes

Cool.

Huh. I don't pay enough attention to what git says about number of insertions and deletions when the numbers are high.

But I thought it's number of lines, and searching the web seems to say stuff that agrees with that.

The Git documentation seems to assume I know what an insertion is and what a deletion is.

Maybe I'm looking in the wrong places.

I can't blame the documentation too much for that assumption.

I assumed that I knew that, too! :)

Is it possible that you have the dotglob shell option enabled?

Pretty much all I find when searching the web for what insertions and deletions are is this post. I do think they're lines added and removed (respectively), though.

If you have dotglob enabled then your recursive glob may have matched files in the .git directory, which is a subdirectory git made in the top-level directory of the repository where it stores the various files it uses to keep track of the repository. Those would increase the count.

You can run git ls-files to list the files git has in its index (which, if nothing is staged, is what's in the repo).

bb soon

I'm back (for a bit).

@Zanna What does git status show?

@EliahKagan it is off

k

$ git status
On branch master
nothing to commit, working tree clean

Well, I don't know why there were so fewer insertions than lines in your files.

I've not heard of git commits mysteriously not including stuff.

You can write globs in .gitignore files that tell git to ignore some files, but you haven't done that.

One way to test if the commit covered all your files would be.... to delete them! :)

If you delete stuff in your repository and then run

git checkout .

at the root of the repository, that should get it back.

You have backups but you might want to make a copy of the repo anyway for easier comparison.

You can also, of course, push the repository to a remote, then clone from the remote and compare. But I suggest just using your file browser (or cp -r or rsync) to copy the repository, then delete all the top-level directories except for .git from one of them.

@EliahKagan it worked :)

Cool. Who knows. As you can no doubt tell, I'm a git user but not a git expert. :)

I should probably have mentioned, since you talked about parallel directory trees int which you were going to move things...

...that git doesn't track empty directories.

Like, if you have empty directories, there's nothing to stage or commit for them.

And if a commit removes all files in a directory, checking out that commit typically removes the directory too.

If you need to keep a directory, the common approach is to put a file in it.

An empty file called .gitkeep is common. git doesn't treat that name specially.

In practice, I think you usually you don't need to keep empty directories.

So... you should try making some more changes and committing them! :)

I should

but I think I will do that tomorrow

Or you could set up a remote. But I suggest committing, creating a branch, and moving between it and your master branch first. (I don't mean to do those things first in general--just when you've hardly used git before.)

@Zanna That makes sense. :)

yes, to practise :)

thanks so much for teaching me :)

if you have some time later, I will be very grateful for more instructions

You're welcome! My own lack of knowledge about a banal and ubiquitous thing took up a good bit of your time... and also informed me of an area where I didn't know what I thought I knew. So I have benefited quite a bit.

@Zanna Sure!

@Zanna Well, that and because, when you work with remotes, you have remote and local branches. Like even if you only have master, if it's tracked on a remote called origin, then you have master and origin/master. I think multiple local branches are a simpler case. Plus, branching is a big part of why git is so popular.