@BlackPanther no idea. Perhaps the official tutorial which is not perfect, and more geared toward people who already know how to program, but alright. docs.python.org/3/tutorial

@AndrasDeak Thanks a lot. That's the one written by Van Rosum I think. It should be great to work through.

I don't know who wrote it originally, and in any case it's probably more of a ship of Theseus by now

@BlackPanther Write some Python code.

The more the better, within reason.

Code that satisfies an actual need, preferably.

A mildly entertaining video about language usage. Totally off-topic, of course.

@FaheemMitha Thanks.

I have n projects in a directory and I want to list the existing remote git repository in each project. How do (1) I enter each project directory, (2) run git remote -v, (3) return to the previous directory, and repeat steps 1 - 3?

Is this the way to do it?

$ for dir in $(ls *);do cd dir; git remote -v; cd ..;done

@BlackPanther That won't work unless everything is a directory.

And you probably don't want to assume that is the case.

How can I generate the string "1 2 3 4 5 ... n" in Bash, for some given n?

@FaheemMitha I updated that command to this:

for dir in $dirs;do cd $dir; git remote -v; cd ..;done

Now I get the error:

bash: cd: $'\E[0m\E[38;5;30mDir1\E[0m': No such file or directory
fatal: not a git repository (or any of the parent directories): .git
bash: cd: $'\E[38;5;30mDir2\E[0m': No such file or directory
fatal: not a git repository (or any of the parent directories): .git

@FaheemMitha slightly related: there are 830 languages spoken in Papua New Guinea en.m.wikipedia.org/wiki/Languages_of_Papua_New_Guinea

@BlackPanther where did $dirs come from?

also watch out for spaces in dir names

@AndrasDeak dirs=$(ls)

I bet those control chars do colouring, which is probably one reason why you shouldn't parse the output of ls. Can't you use for dir in *?

@AndrasDeak I remember I set up ls colors so that I can get colored output from ls. Thanks, that was the problem. for dir in * works.

@FaheemMitha Looking in a few minutes

I now have the following that works better, but not perfectly because I want to skip non-directories

for dir in *;do cd $dir; echo $dir; pwd; git remote -v; cd ..;done

I need to use an if statement that skips non-directories

Is the following correct?

@BlackPanther try it

Literally easier to try than to ask us

for dir in *;do if [$dir == "*.*"] then cd $dir; echo $dir; pwd; git remote -v; cd ..; fin; done

@AndrasDeak Yeah, I'm working on it

At least one ; is missing before then I think

and there's probably a semantic error

I'd google the problem you're trying to solve

I.e. test for being a directory, or just looping over directories

Successive approximation via trial and error is not very sustainable

Even if the comparison worked and you flipped the comparison *.* is not a good filter for non-directories

I have this now:

$ for dir in *;do if [["$dir" = *.*]]; then cd $dir; echo $dir; pwd; git remote -v; cd ..; fin; done
bash: syntax error near unexpected token `done'

"fin"?

But I'll stop helping now

yeah it's fi.

I'm no longer using an if statement.

The following code pipes the output of git remote -v to grep which should select lines that don't contain the pattern fatal.

$ for dir in */;do cd $dir; git remote -v | grep -v fatal; echo $dir; pwd; cd ..; done

However, lines that contain the pattern fatal are still in the output.

Any idea why?

@AndrasDeak do you have an idea why grep -v doesn't select only lines that do not contain the pattern fatal?

The problem is that fatal: not a git repository (or any of the parent directories): .git is an error, and is therefore sent to the standard error stream. A pipe takes the standard output of a command not the standard error, so grep never sees fatal: not a git repository (or any of the parent directories): .git since fatal: not a git repository (or any of the parent directories): .git is sent to the terminal, not the pipe, that is, the pipe does not redirect an error.

@Fabby Ok.

Don't get your hopes up. It's a very unexciting email.

Once upon a time I used to write emails that were practically Literature. But that time is long gone.