@EliahKagan oh! I was thinking it wouldn't matter much where, but evidently it does XD

What happened there?

I'm not familiar with xclip

The problem wasn't related to the text the alias was supposed to expand to.

The shell parses this as one word:

pbpaste='xclip -selection clipboard -o'#

Oh of course

Then the shell metacharacter ( appears in a subsequent word of the same command, in a context where the shell cannot give it any meaning. But it is unquoted. So that's a syntax error.

To avoid that problem, it doesn't actually matter where in the file one advises readers to put the alias definitions, so long as it's clear that they need to go on lines of their own.

As a secondary problem, which I don't expect to usually cause any trouble for alias definitions... it's generally bad to put code in .bashrc before this check except when one deliberately intends that it run in some non-interactive shells:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

(This advice is largely specific to Debian and its derivatives, including Ubuntu, since other systems rarely have that check. They also often compile bash with a different configuration that is less likely ever to identify anything as the initial shell of a non-interactive remote session.)

Incidentally, this is one of the main reasons I had so much trouble figuring out, and actually never did end up figuring out, how to improve that old post while having it still make sense and without having it convey wrong information (either directly or by being confusing and leading to wrong assumptions).

But I did end up answering a question where a user suffered the practical effects of this misconception. I think this should make it easier to improve the old post.

@EliahKagan But I still don't know how to make the change well. The default behavior in Debian and Ubuntu for which bash shells source .bashrc on startup and which don't is that

(a) interactive non-login shells source .bashrc directly

(b) login shells source .bashrc indirectly whether or not they are interactive because both interactive and non-interactive login shells directly source .profile, the default contents of which source .bashrc when the running shell is bash, and the code for that is not guarded by an interactivity check

(c) non-interactive non-login shells source .bashrc when bash heuristically detects that it appears to be the inital shell in a remote session, which on some OSes literally never happens, but which on Ubuntu and Debian happens quite often, such as in ssh remote-host some-command.

In the post I bascially say that .bashrc is always sourced, which is better than the usual claim that it is only sourced in interactive non-login shells (a claim that confuses the mechanism with the result and also is wrong about the mechanism). But it's still pretty bad. Like, running a script with bash -c some-commands or bash /path/to/script doesn't run .bashrc ...except sometimes when run via ssh.

← 21 messages moved from Raiders of the Lost Downboat

@EliahKagan @Zanna Also, did you want to post a self-answered question about the meaning of "insertions" and "deletions" when git is run on a repository that contains some binary files? [Seemingly unnecessary self-ping for continuity if this part of the conversation is moved to the Island.]

You have never committed to doing this or even suggested you would, btw. I had just suggested it. You figured out it was probably due to the images before I did, so you really did solve it.

ooh good idea

hmm

:( I'm preoccupied

← 5 messages moved from Raiders of the Lost Downboat

→ 5 messages moved to Raiders of the Lost Downboat

@Zanna That sounds less fun than if you were preoccupied.

@EliahKagan that would be way more fun

some bureaucracy & stuff to deal with