When starting a new bash shell, dietpi-banner is called, but it’s not aliased in my .bash_aliases or /etc/bash.bashrc. How is it invoked? Can I block/disable it?
I’m trying to sort out some weird behavior in screen (commands not being run at start) and I want to see if banner is somehow interfering with them.
The alias is defined in /etc/bashrc.d/dietpi.bash, which is sourced on every interactive login.
It calls then dietpi-login.
There is a hint in dietpi-login on how to disable the banner:
# Show DietPi banner if not disabled via ~/.hushlogin
[[ -f ~/.hushlogin ]] || /boot/dietpi/func/dietpi-banner 1
Maybe you wanna share what commands are not running on login?
And sourcing scripts from /etc/bashrd.d itself is implement in /etc/bash.bashrc (last line).
In fact, while dietpi-banner can be used to toggle certain output lines/sections, there is no way to selectively disable the banner only.
touch ~/.hushlogin mutes /etc/motd (the Debian login text) as well./etc/bashrc.d/dietpi.bash also prevents loading the dietpi-* aliases and G_* functions+variables into the shell. And dietpi-update reverts it./etc/bash.bashrc would be persistent, but additionally prevents loading other scripts from /etc/bash.bashrc, used e.g. for CLI aliases for certain dietpi-software installations, and bash-completion in non-login shells.Probably worth a feature, though I don’t remember anyone asking for this, if not for debugging like there. For that, the current ways are probably good enough.
but the banner is loaded on shell login only. As I understood from OP, he has issued with some stuff during startup. At least I don’t see a relation.
Ah, I wasn’t clear. I was having an issue when starting screen. The stuff commands weren’t executing as expected (e.g., stuff "ls^M" wasn’t listing.)
Creating ~/.hushlogin seems to have done the trick, although I’m not sure why the banner was interfering. The nice thing is I can call the banner directly in windows that don’t have anything else going on. (It’s also nice to know there’s a way to call it without invoking the settings dialog.) I’m tempted to alter dietpi-login to detect if screen is running, but since it usually is on my machines I probably won’t bother.
Thanks, Jappe & Michalng!
I am not sure about the ordering/timing when screen is loaded, but I’d assume the banner to run after stuff pasted the string. Since the banner moves the current terminal content into scrollback buffer (if there is any), it probably move up the listing likewise.
However, using staff to simply run the ls command seems weird and hacky. I mean it works, but wouldn’t it make more sense to use .bashrc or similar, if you simply want to run a command on login? If you want to assure it runs after the banner, you could add it via /etc/bashrd.d/zz-ls.sh or so, anything that is alphanumerically sorted after /etc/bashrc.d/dietpi.bash. That would be for all users, of course.
Unless I’m missing something, that would run for every login.
I’m using stuff to set up workspaces in different screen windows. One would ls a directory, another would run irssi,etc.
Ah, and you send the commands with -X stuff 'ls^M'?
Did you check, i.e. running screen from within an SSH session, whether the issue really is the ordering, and the output of your command is above the banner?
Probably not that easy to solve. You could pass a variable through screen and run that via bashrc, if defined. To assure that it really runs after the banner and any other profile/bashrc command:
PROMPT_COMMAND='ls; unset PROMPT_COMMAND' screen
That run ls right before the first command prompt, then unset itself to not repeat on next command prompt.
A true solution our end would be to move the dietpi-banner to /etc/update-motd.d/, so it runs as native shell MOTD, and not as bashrc command afterwards. But the problem is that this runs only on login shells, not when e.g. opening a terminal emulator, running bash as is, or screen (unless shell -/bin/bash is explicitly set). I like the banner to appear on really every interactive (bash) shell, no matter how/where it is started.
It’s actually set in my .screenrc file, but same idea.
Looking closer, it seems that screen is injecting the command at the same time that banner is outputting. They show up in the middle of the certificate status on my setup:
- Let's Encrypt cert status : ls
Valid until 2026-etc.
The placement is oddly consistent across different screen windows.
I’m satisfied with using .hushlogin and calling the banner directly. I realized you can also have multiple commands in stuff, so the following works to give the banner and a listing:
stuff "/boot/dietpi/func/dietpi-banner 1;ls^M"
And how do you control which command to paste into which workspace, if they use (the same) .screenrc? Or is it different users?
Makes sense, like you can type stuff before the first command prompt appeared, while /etc/bash.bashrc, /etc/profile, their user instances etc run. So its asynchronous and depends on how long other stuff in /etc/screenrc and ~/.screenrc takes.
If it is a non-root session, sudo is invoked to check the cert status, which takes a bit longer. So it gives a larger time window. With next DietPi version, the banner went through some internal changes, including the fact that key and value of a banner entry are printed in one step. So you’ll see the ls in a separate line then (which of course doesn’t really make anything better 
).
Probably the best workaround 
.
.screenrc lets you set up different windows on launch. E.g.:
defshell -$SHELL # Set login shell
screen -t WORK 0 # Start a window for current dir titled WORK and numbered 0
stuff "/boot/dietpi/func/dietpi-banner 1;ls^M" # Run banner and ls
chdir $HOME # Change to home dir
screen -t HOME 9 # Start another window
stuff "nano .screenrc^M" # Open .screenrc in nano
select 0 # Make the initial window the current one
Now when screen starts up you’ll have two windows with different contents waiting. You can get even fancier 
Oh wow, looks like I never used the full potential of screen. I mostly use it to prevent long-running foreground commands to terminate on SSH connection loss, and to quickly create and destroy temporary windows, most commonly when having a file opened in a CLI editor, where I need to copy&paste output from another console command.