Re: Lost internet access on Trixie this morning.

[Greg Wooledge]

On Mon, Sep 16, 2024 at 15:47:10 -0400, Dan Ritter wrote:
> Tom Furie wrote: 
> > Actually, it doesn't look good - you don't have any ip addresses on eno1,
> > the interface is down. You're going to have to find out why that is.
> 
> Since it's recognized, it was probably not configured.
> 
> Easiest: edit /etc/network/interfaces to include these lines for
> eno1:
> 
> --
> iface eno1 auto
> iface eno1 inet dhcp
> --
> 
> And then run
> 
> sudo ifup eno1
> 
> to get it running.

Didn't the initial message say that the Internet *was* working, and then
suddenly *stopped* working, right in the middle of a download?

That, together with the interface not being UP, points to the
configuration being OK, but something going wrong at the hardware or
kernel level, I think.

(Unless of course a configuration change was made during that download.)

Re: unwanted crontab message

[Greg Wooledge]

On Fri, Sep 13, 2024 at 22:46:09 +, Andy Smith wrote:
> I just ran crontab -e as a fresh user and it actually invoked
> /usr/bin/sensible-editor and asked me which editor I wanted to use
> (now and in future). So perhaps the man page for crontab is out of
> date.

Agreed.

hobbit:~$ strings /usr/bin/crontab | grep usr/bin/
/usr/bin/sensible-editor

The man page is simply wrong, I think.

Re: unwanted crontab message

[Greg Wooledge]

On Sat, Sep 14, 2024 at 05:44:42 +0800, Marcus Park wrote:
> Hi list,
> 
> When I run 'crontab -e' the screen shows some errors like,
> 
> $ crontab -e
> Error detected while processing /usr/share/vim/vim82/filetype.vim:
> line   10:
> E319: Sorry, the command is not available in this version: let
> did_load_filetypes = 1

What version of Debian is this?

What version of the vim package (or any similarly named package) are
you running?

Did you do anything *noteworthy* with this system, such as attempting
an upgrade from one version of Debian to another, having it fail, and
leaving it half done?

For the record, Debian 12 has vim 9.0.x and a /usr/share/vim/vim90/
directory.  According to ... oh,
that web page is not responding for me.  Sorry, I can't check what
version(s) of Debian might have had vim 8.2.

Anyway, it sounds like you have vim 8.2 config files, but you're running
an *older* version of vim which can't read those configs.  Either that,
or the /usr/share/vim/vim82/filetype.vim file is corrupted.  If it's
a corrupted file, you could purge and reinstall the vim package(s).

Re: scp in crontab problem

[Greg Wooledge]

On Fri, Sep 13, 2024 at 20:24:51 +0800, Marcus Park wrote:
> I have put the private key into my debian VPS (in ~/.ssh/ dir).

Does this private key have a passphrase?

> When I scp a file from this VPS to another one by hand without password, it
> works.
> 
> But when I put this scp into crontab, it seems not work. The scp in crontab
> via private key didn't run as I expect, nothing was copied to peer.

First question: what did the output say?  Any output from the cron job
should have been mailed to you.  If you don't have a mail reader set up
on this machine, try "less /var/mail/$LOGNAME" or something.  If you
don't have local mail delivery set up, fix that.

Second question: if the key has a passphrase, are you using an ssh-agent
to invoke it normally?  The cron job won't have access to your ssh-agent,
not without a bunch of additional setup.

For automated jobs, you usually need the private key to NOT have a
passphrase.  And yes, this is a large security concern.  You'll have
to balance your security needs against your application needs.

Re: Circumventing keyboard problem on Lenovo R64

[Greg Wooledge]

On Thu, Sep 12, 2024 at 14:50:23 +0100, Joe wrote:
> On Thu, 12 Sep 2024 08:35:25 -0500
> Richard Owlett  wrote:
> > Relevant man page to have 'root' edit a user's login name?
> > 
> Looks like usermod, according to the first page Google shows for:
>   debian change user name

I prefer vipw(8).  But that's just me.

You'll also want to read passwd(5) and shadow(5).

I would highly recommend *not* being logged in as the user whose name
is being changed at the time.  Do a direct root console or ssh login.
Unless you have a second unprivileged account that can su/sudo to root
to make the changes to the first account.

You'll probably want to rename the home directory, so mv(1) applies.

If the user has a crontab file, you may want to find that and rename
it as well.

If you're using /var/mail for user mailboxes, you may want to rename
the user's mailbox file too.

There may be other things I can't think of right now.

Re: startx returns "Xf86EnableIO: failed to enable I/O ports 0000-03ff"

[Greg Wooledge]

On Wed, Sep 11, 2024 at 17:16:37 +0200, Pierre Willaime wrote:
> systemctl status dbus.service  shows dbus is not active ("failed") and I have 
> this message
> 
> Failed to start message bus: Circular inclusion of file 
> '/etc/dbus-1/system.conf'

Curious.  I have nothing that references that file at all.

hobbit:~$ ls -l /etc/dbus-1/
total 8
drwxr-xr-x 2 root root 4096 Sep 16  2023 session.d/
drwxr-xr-x 2 root root 4096 Feb 17  2024 system.d/
hobbit:~$ grep -r -F system.conf /etc/dbus-1
hobbit:~$ 

(That's on Debian 12.)

Re: BASH reference for those who are "learning by doing"?

[Greg Wooledge]

On Sun, Sep 08, 2024 at 06:48:30 +0200, Sirius wrote:
> Bash has some nifty uses when it comes to variables.
> 
> If you just want to store a file in a variable,
> VAR="$( will do it. If you want to do an array instead, use the 'while read line;
> do' construct. As others have pointed out, this is not an optimal usecase
> for bash.

Unless you're targeting very old versions of bash, you can read the lines
of a file/stream into an array with the "readarray" (or "mapfile") command.
You can specify a single character to act as the line terminator, or
let the default newline character $'\n' be used.  In sufficiently new
versions of bash, you can specify '' to use NUL as the line terminator.

For example, in bash 4.4 or higher:

readarray -t -d '' myfiles < <(
find . -type f -print0
)

You almost always want the -t option, to strip the delimiter from the
array elements.  In the case of NUL, it makes no difference, but it's
a good habit to have if you ever use this technique on text files.

Just to reiterate what others have said: do *not* use bash's text
processing tools or regular-expression-based techniques to parse HTML.
See .

Re: BASH reference for those who are "learning by doing"?

[Greg Wooledge]

On Sat, Sep 07, 2024 at 22:00:27 +, Quaeryth wrote:
> A query like "site:stackoverflow.com bash how to read file into variable" via
> Google or DuckDuckGo (and maybe other search engines) usually points me in
> the right direction. Good luck with your experiments!

What kind of file?
What kind of variable?
What are you planning to do with the variable after you've stored data
in it?

The fundamental problem with this question is that bash variables *can't*
store all kinds of data.  Specifically, they are unable to store the NUL
byte (ASCII 0x00), so storing any kind of binary file is off the table.

So, that leaves text files.  You can, in theory, store a text file in
a bash variable -- but why?  What's the point?  Are you going to copy
that data out to another file?  If so, you'd be better off just copying
the original text file with the cp command, instead of reading the data
into a shell string variable and then writing it back out.  Bash is
abysmally *slow* at such things.  Running cp would most likely be faster,
for non-tiny files, even if you have to run it several times.

But maybe this is an X-Y problem, and the real question is something
like "I want to iterate over the lines of a file.  For each line, I
want to do ."

In that case, reading the entire file into a string variable is a poor
first step.  Now, you *might* read the entire file into an *array*
variable (one line per array element), and then iterate over the array.
That's not the worst thing you could do.

But even that may not be necessary.  If you don't need to pre-read the
entire contents, then don't.  Just read one line at a time, and process
each line as you read it.

That's Bash FAQ #1.  

Re: tab completion being overenthusiastic

[Greg Wooledge]

On Sat, Sep 07, 2024 at 09:58:32 -0400, e...@gmx.us wrote:
> Got it.  It was in ~/.bash-vars which was sourced from ~/.bash_profile .  Is
> that a standard thing, or just some "brilliant" idea I had once upon a time?

It's not a standard file.

By the way, there's a trick you can use to find out where shell variables
are being defined:

PS4='+ $BASH_SOURCE:$FUNCNAME:$LINENO:' bash -ilxc : 2>&1 | grep CDPATH

The -il options run an interactive login shell.  If you need to check an
interactive non-login shell instead, just change the options to -ixc.

This won't work as root, because PS4 from the environment is suppressed
for security reasons when running bash as root.

Re: tab completion being overenthusiastic

[Greg Wooledge]

On Sat, Sep 07, 2024 at 08:56:08 -0400, Eben King wrote:
> Hi.  I have bash 5.2.15(1).  When I cd into an empty directory, and type "cd
> ", the shell offers 178 possibilities.  If I restrict it to an
> initial letter and hit  once, I think the spurious offerings are from
> $HOME.  How can I make it not do that and only offer me things I ask for?

Do you perhaps have the CDPATH variable set?  That might affect tab
completion for the cd command.

Re: OT: Question to shell script

[Greg Wooledge]

On Fri, Sep 06, 2024 at 11:10:16 +, Andy Smith wrote:
> Is there a reason not to just make these scripts cd to their own
> directory so the caller doesn't have to care?
> 
> cd "$(dirname "$0")"

https://mywiki.wooledge.org/BashFAQ/028

Re: OT: Question to shell script

[Greg Wooledge]

On Fri, Sep 06, 2024 at 12:25:11 +0200, Hans wrote:
> I have several directories, and in each directory there is a shell script, 
> which MUST be started within and from its path. 

I'm not clear on what "within and from its path" means here, but let's
suppose you mean "I have to cd there first, and I also have to use the
full pathname of the script, rather than ./script."

> The structure looks like this:
> 
> /directory-one/application_1/my-shell-1.sh
> /directory-two/application_2/my-shell-2.sh
> /directory-three/application_3/my-shell-3.sh
> 
> Of course, I could mae my master-shell-script so, that I first go into the 
> first one, execute, then cd to the second one, execute and last cd to the 
> third one, execute, but I suppose, there is an easier way. 

You can populate an array with all of the script paths, then iterate
over it.


#!/bin/bash
scripts=(
/directory-one/application_1/my-shell-1.sh
/directory-two/application_2/my-shell-2.sh
/directory-three/application_3/my-shell-3.sh

# We can use blank lines and comments in here.
# /directory-four/application_4/my-shell-4.sh
)

for s in "${scripts[@]}"; do
dir=${s%/*}
cd "$dir" && "$s"
done


This particular script does *not* force each cd/execute to occur in a
subshell, because we don't actually have to return to our original
directory at any point, ever.  It's totally fine to remain in the
first script directory until we cd to the second script directory.
If any of the cds fails, we simply skip that script and move on to the
next.

Re: Usage: "debian ... amd64-netinst.iso"

[Greg Wooledge]

On Wed, Sep 04, 2024 at 12:57:52 +, David wrote:
> On Wed, 4 Sept 2024 at 11:03, Max Nikulin  wrote:
> > On 04/09/2024 15:17, Thomas Schmitt wrote:
> 
> > In /tmp/check_debian_iso line 153:
> > sum_from_file=`dd if=$file bs=2048 count=$blocks | $checksummer | head
> > -1 | awk '{print $1}'`
> >   ^---^ SC2086 (info): Double quote to prevent
> > globbing and word splitting.
> 
> Hi, that particular SC2086 warning can be ignored because the
> $1 that it is mistakenly complaining about is awk syntax, and the
> shell will not touch that because it is inside single-quotes.

Is it, though?  It looks more like it's pointing to the if=$file part.
Perhaps the indentation was mangled by the layers of quoting.

> Whether and whether any of $file, $blocks, $checksummer
> need to be double quoted is a matter of preference, if their
> contents is known to not contain whitespace or globbing
> characters.

There is no sane world in which $file should be left unquoted.
Filenames *frequently* contain whitespace.  It should be assumed that
*all* filenames contain whitespace -- you're just better off writing
from that perspective.

count=$blocks ... now, that one could go either way.  The quotes are
*probably* not needed, assuming the contents of $blocks are a number.
But it's still better to include the quotes, to save the shell from
having to undergo the additional work of scanning the word for IFS and
globbing characters.

$checksummer here is a special case.  The way it's written is a horrible
hack that Bourne shell programmers seem to have embraced.  The idea is
that you can put a command and its arguments inside a variables, separated
by spaces, and use the variable unquoted to expand to the command.

This "works" in the simplest cases, where every argument word is just
a series of alphanumeric characters with carefully constrained punctuation
characters (dot, hyphen, underscore).

It **completely fails** if one of the arguments is a filename that
contains whitespace.  Or contains whitespace for any other reason, such
as being something like CFLAGS='-g -O'.

The workaround for that is to use an array instead of a string variable
to hold the command and its arguments.

checksummer=( md5sum --magic-arguments )
dd if="$file" | "${checksummer[@]}" | awk 'stuff'

Of course, that's a bash extension, and not available in sh.  In sh,
there is simply no way to do this safely, unless of course the contents
of checksummer are static.  In that case, checksummer can be written
as a function.

checksummer() { md5sum --magic-arguments; }
dd if="$file" | checksummer | awk 'stuff'

Re: /var/backups, how to restore ?

[Greg Wooledge]

On Tue, Sep 03, 2024 at 14:08:37 +0200, Erwan David wrote:
> I backup them on other disks, but if my PC crashed, how an I use this
> to install a new PC, with same packages ?

If all you want is the list of packages, your best bet would be to ignore
*all* of those files, and create a new backup of:

dpkg --get-selections

Just redirect that to a file, and save that file along with your other
backup files.  You don't even need to be root for this step.

To load that list of packages on a new installation, you use these
commands:

dpkg --set-selections < your-file
apt-get dselect-upgrade

(You must be root for those.)

Re: Usage: "debian ... amd64-netinst.iso"

[Greg Wooledge]

On Sun, Sep 01, 2024 at 01:19:45 -0700, David Christensen wrote:
> On 8/31/24 23:16, Timothy M Butterworth wrote:
> > On Sat, Aug 31, 2024 at 11:15 PM David Christensen wrote:
> > > On 8/30/24 20:48, John Conover wrote:
> > > > What does a "debian ... amd64-netinst.iso" do
> > > > with an .iso?

> Yes -- but the command in the given string is "debian", which is not a valid
> command.

Stop being so blindly literal.  It's pretty obvious to *most* of us
that John was referring to an .iso file, presumably one that he had
downloaded, and now was asking what to do with.

So many of the replies in this thread have been disappointing.

The best reply would be to point John to the Debian Installation Guide:


Specifically, Chapter 4, "Obtaining System Installation Media":


This tells you what to do with the .iso file, if you're already on a
Linux system with appropriate hardware.  It also links to the Debian CD
FAQ, which contains hints on what to do on non-Linux systems.

Re: emacs service and session start

[Greg Wooledge]

On Fri, Aug 30, 2024 at 13:45:43 +0200, Erwan David wrote:
> The after/wants does not work (starnge since ssh-agent.service seems
> to see the SSH_AUTH_SOCK variable.
> 
> But /etc/X11/Xsession.d/90x11-common_ssh-agent is a configuration file
> and we can add SSHARGS. I added a
> SSHARGS="-a $XDG_RUNTIME_DIR/ssh-agent"
> 
> Then I added an override to emacs.service
> Environment=SSH_AUTH_SOCK=%t/ssh-agent
> 
> And it works

It's amazing how badly the systemd folks managed to break *everything*.

I'm pretty old-fashioned.  I use startx from a console login, and I
configure it with a ~/.xsession file which overrides the Debian stuff.

In my .xsession file I have:

hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)"
hash ssh-add 2>/dev/null && ssh-add 

Re: Replying to a conversation (Thread)

[Greg Wooledge]

On Sat, Aug 24, 2024 at 14:36:09 -0700, Joe B wrote:
> IF i see a thread i want to jump into to help out how can i be part of
> the conversation? as of right now i'm just putting the debian-user
> list email and the RE with the subject and replying that way.
> 
> I noticed on the list there is a message id. is it possible to copy
> the message id to the email so the chain just keeps going ?

If your MUA doesn't have an explicit "reply to list" feature, then just
use "reply all", and remove everything except the list address from
the headers.

If you don't do a reply, then the In-Reply-To header which places your
message into the thread won't be set up, and your message will just
be a new thread with the same Subject as an existing one.  Some of the
archives may be clever enough to attempt thread joins via Subject header +
Date as well as the normal In-Reply-To header, but some may not.

If for some reason you ever NEED to construct a reply manually, what
you're doing is a good start.  You just need to copy the Message-Id
from the message to which you're replying, and add an In-Reply-To header:

In-Reply-To: 

The   are literal here; you should add them.

Re: update-alternatives: install with permanent arguments

[Greg Wooledge]

On Thu, Aug 22, 2024 at 14:33:22 +0300, Dmitrii Odintcov wrote:
> Hi Greg,
> 
> 
> This has occurred to me, but seemed like a bit of a hack and less
> convenient to transfer to other machines...
> 
> > do it manually, not with update-alternatives
> Why so? Could I not feed the script path to update-alternatives install?

Well, if it works, then I guess it's OK.

Re: update-alternatives: install with permanent arguments

[Greg Wooledge]

On Thu, Aug 22, 2024 at 13:09:06 +0300, Dmitrii Odintcov wrote:
> Let's say I want to install VS Code / Codium as an alternative for
> `/usr/bin/editor`, but I want it to always run with `--wait
> --reuse-window` so that other software can rely on the editor
> returning after the file is saved (like `crontab -e` does, for
> example)
> 
> I cannot do `update-alternatives --install /usr/bin/editor editor
> "$(which codium) --wait --reuse-window" 0` because the "alternative
> path doesn't exist".
> 
> Suggestions?

Write a wrapper script like


#!/bin/sh
exec codium --wait --reuse-window "$@"


and use this script as the symlink target of /usr/bin/editor (do it
manually, not with update-alternatives).  Don't forget to chmod 755.

Re: What tool(s) reports OS buss width, which processor present?

[Greg Wooledge]

On Wed, Aug 21, 2024 at 13:39:22 +0200, to...@tuxteam.de wrote:
> On Wed, Aug 21, 2024 at 06:34:30AM -0500, Richard Owlett wrote:
> > I know I've asked this before, but couldn't thread.
> > /etc/debian_version reports release active, but I need to know 32 or 64 bit.
> > TIA
> 
> uname -a
> 
> This tells you the *kernel* version. Note that for most architectures,
> the 64 bit version can run 32 bit applications fine if you make sure to
> have the libs installed.
> 
> So "the release 'is' 64 bit" or "... 32 bit" is misleading.

I've always favored "file /bin/ls" to get the architecture.

hobbit:~$ file /bin/ls
/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically 
linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=15dfff3239aa7c3b16a71e6b2e3b6e4009dab998, for GNU/Linux 3.2.0, 
stripped

It's extremely likely that whatever arch /bin/ls uses is the "primary"
arch for the system.  It works on every Linux system I've encountered,
even if the kernel doesn't match it.

Of course, for Debian specifically, there's also

dpkg --print-architecture

If that agrees with file /bin/ls, then you've got one more level of trust.

Re: Metapackaging

[Greg Wooledge]

On Wed, Aug 21, 2024 at 11:57:06 +0100, Jonathan Dowland wrote:
> On Tue Aug 20, 2024 at 1:55 PM BST, Greg Wooledge wrote:
> > You're saying that you use equivs to create packages that have the SAME
> > NAMES as Debian packages??
> 
> That's entirely the point of it, surely. You want to convince the
> packaging system that you have dependency $FOO satisfied, even if you
> don't. You create an "equivalent" metapackage.

The only way I've used equivs is to produce a package named mta-local
which looks like this:

hobbit:~$ dpkg -s mta-local
Package: mta-local
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 9
Maintainer: Equivs Dummy Package Generator 
Architecture: all
Multi-Arch: foreign
Version: 1.0
Provides: mail-transport-agent
Conflicts: mail-transport-agent
Description: A local MTA package
 A package, which can be used to establish a locally installed
 mail transport agent.

It provides mail-transport-agent, so programs like bsd-mailx have their
dependencies satisfied.

I run a locally compiled qmail installation, not from the Debian packages,
if such packages even still exist.

The idea that I would do this but name it something like "sendmail"
instead of "mta-local" sounds extremely sketchy.

As I said previously, I know some other people use equivs to generate
a package of their own making that contains a bunch of Depends lines,
to bring in all of the software they want during a new installation.
In that case, it would also not make sense for their locally built
package to share a name with any Debian package.

Re: wait until swapoff is *actually* finished (it returns too early)?

[Greg Wooledge]

On Wed, Aug 21, 2024 at 08:39:37 +0200, Erwan David wrote:
> On Wed, Aug 21, 2024 at 02:18:44AM CEST, Greg Wooledge  
> said:
> > On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. Sánchez wrote:
> > > sync && sync && sync && swapoff
> > > 
> > > I couldn't tell why I have sync 3 times, but I know that it's how I've
> > > called swapoff since as far back as I can remember.
> > 
> > Cargo cult.  It was never useful to the best of my knowledge.
> 
> Once upon a time, the sync command would return before the actual
> syscall where completed. Doing 3 times sync gave you a very high
> probability that the first one indeed completed all its writes.
> 
> But it was already false in SunOS 4 (~1990)

Even if that's true, running them all in the same command as Roberto
shows would not give you any benefit.

You'd need to physically *type* the command and press Enter three times
to get any "protection".  And even then, it's really just the extra
time that it takes to type those commands out.  You'd get the same
"protection" by simply waiting 10 seconds (or whatever's appropriate)
after running sync once.

Re: wait until swapoff is *actually* finished (it returns too early)?

[Greg Wooledge]

On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. Sánchez wrote:
> sync && sync && sync && swapoff
> 
> I couldn't tell why I have sync 3 times, but I know that it's how I've
> called swapoff since as far back as I can remember.

Cargo cult.  It was never useful to the best of my knowledge.

Re: configuring tigervnc-standalone-server to listen on LAN

[Greg Wooledge]

On Tue, Aug 20, 2024 at 15:28:40 -0400, Gary Dale wrote:
> Look, I know the executable is vncserver. The question is how do I get the
> service to specify parameters when starting the service? I can start is from
> the command line as "vncserver -localhost no" but then I'd have to use cron
> to set it up to run on reboot, something the systemd service already
> handles.

Are you sure you actually *want* to use systemd to start it?  It doesn't
really seem like the best choice to me.  For one thing, when you start
it from a user's crontab with @reboot, it runs as the correct user
automatically.  I don't know how systemd knows which user to start the
VNC session as.

Maybe I just don't understand the concept of a "standalone (VNC) server".

I've got some workstations with tightvncserver installed, and I've got
two sessions running on each workstation, as two separate user accounts.
Each one is started from the user's crontab file, with a customized
resolution for each human user.

Re: configuring tigervnc-standalone-server to listen on LAN

[Greg Wooledge]

On Tue, Aug 20, 2024 at 15:04:11 -0400, Gary Dale wrote:
> On 2024-08-19 22:27, Max Nikulin wrote:
> > On 20/08/2024 05:15, Gary Dale wrote:
> > > tigervnc-server has a command line option to listen to the LAN but
> > > the Debian systemd service configuration doesn't invoke the server
> > > program directly, so I'm not sure how to get the option to the vnc
> > > server.
> > [...]> This is the .service file:
> > [...]
> > > ExecStart=/usr/libexec/tigervncsession-start %i
> > 
> > Try "systemctl cat" for the corresponding .socket file.
> > 
> > 
> > 
> Thanks, but I can't find a .socket file.  While
>     find / -name *.service | grep vnc
> locates the various .service files associated with vnc:
> /etc/systemd/system/multi-user.target.wants/tigervncserver@:1.service
> /etc/systemd/system/vncserver@.service
> 
> The same search for *.socket comes up empty.

If you know the package name, you can get a list of files which are part
of that package.  If it's installed locally, you can use dpkg -L to get
the filenames.  Otherwise, you can use Debian's web site:

https://packages.debian.org/bookworm/amd64/tigervnc-standalone-server/filelist

I'm guessing that's your package name.


File list of package tigervnc-standalone-server in bookworm of architecture 
amd64
/etc/X11/Xtigervnc-session
/etc/tigervnc/vncserver.users
/lib/systemd/system/tigervncserver@.service
/usr/bin/Xtigervnc
/usr/bin/tigervncserver
/usr/libexec/tigervncsession-start
/usr/sbin/tigervncsession
/usr/share/doc/tigervnc-standalone-server/changelog.Debian.gz
/usr/share/doc/tigervnc-standalone-server/copyright
/usr/share/man/man1/Xtigervnc.1.gz
/usr/share/man/man1/tigervncserver.1.gz
/usr/share/man/man8/tigervncsession.8.gz


... oh wait, the package name is in the Subject.  Gah, I hate it when
people hide details in the Subject header instead of the body.

Well, at least I guessed the right package name.

Re: Metapackaging

[Greg Wooledge]

On Tue, Aug 20, 2024 at 12:26:39 +0100, Jonathan Dowland wrote:
> On Sun Aug 18, 2024 at 5:32 PM BST, Greg Wooledge wrote:
> > On Sun, Aug 18, 2024 at 17:08:00 +0100, Jonathan Dowland wrote:
> > > I've long felt that they were overcomplicated in themselves: the
> > > ideal UX should be not much more than "equivs package-name" =>
> > > ./package-name.deb generated, IMHO. I once had ambitions to add
> > > that UX (either as a patch to equivs, or as a separate equivs-ng)
> > > but I never got around to it.
> >
> > That may be acceptable for packages that don't have any Depends: or
> > Provides: lines or what-have-you.
> 
> I would want this for packages which had depends/provides as well: my
> expectation would be that the generated dummy package would also have
> those depends/provides. It must not have been clear from my brief
> illustration, but my envisaged "equivs" tool would look up the package
> name from dpkg metadata.

This is getting weirder.

You're saying that you use equivs to create packages that have the SAME
NAMES as Debian packages??

Re: upgrade to bookworm causes breakage

[Greg Wooledge]

On Mon, Aug 19, 2024 at 17:33:13 -0500, Bob Mroczka wrote:
> I attempted to upgrade my system from debian 11 to 12 following the
> instructions provided at
> https://www.cyberciti.biz/faq/update-upgrade-debian-11-to-debian-12-bookworm.

I'm not going to read that web site.  I'll just assume it's correct.

What kind of computer are you using?

> dpkg -i gzip_1.12-1_amd64.deb
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> dpkg-deb: error: tar subprocess returned error exit status 2
> dpkg: error processing archive gzip_1.12-1_amd64.deb (--install):
>  dpkg-deb --control subprocess returned error exit status 2
> Segmentation fault
> 
> I attempted to run reportbug from the system but it segfaults after showing
> the list of related bugs.
> 
> I am unable to get a backtrace from gdb since gdb segfaults.

My first thought when I saw that error message was that you've got a
corrupted gzip .deb file.  But if *everything* is segfaulting, then
you've either got a corrupted libc or kernel, or your computer isn't
supported by Bookworm.

Your error message shows you're using amd64, so my second guess (that
you're on one of the Pentium-era i386 CPUs which has been obsoleted)
is also wrong.  I don't know if any specific amd64 CPUs are obsoleted,
but if you post your hardware specs, maybe someone will know more.

If it's not a hardware compatibility issue, then I'm back to "corrupted
file" as the primary guess.

Re: Metapackaging

[Greg Wooledge]

On Sun, Aug 18, 2024 at 17:08:00 +0100, Jonathan Dowland wrote:
> I've long felt that they were overcomplicated in themselves: the
> ideal UX should be not much more than "equivs package-name" =>
> ./package-name.deb generated, IMHO. I once had ambitions to add
> that UX (either as a patch to equivs, or as a separate equivs-ng)
> but I never got around to it.

That may be acceptable for packages that don't have any Depends: or
Provides: lines or what-have-you.

In general, people may be using equivs for a variety of reasons --
for example, a custom local package that depends on all of the packages
needed for a specific server installation.

Re: nvidia driver for GTX 970

[Greg Wooledge]

On Fri, Aug 16, 2024 at 00:48:20 +1000, George at Clug wrote:
> On Thursday, 15-08-2024 at 19:05 Hans wrote:
> > FYI I am running a backport kernel, it is 6.9.7+bpo-amd64.
> 
> Is this what is called a "Frankendebian" ?

No.  Backports are reasonably safe.  Installing one doesn't break all
your dependencies and lock you into the testing or unstable branch
the way an actual Frankendebian does.

(A real Frankendebian results from installing packages from testing,
unstable or experimental on a stable or older-than-stable system.)

> How stable is using a backport kernel in Bookworm?  

I've generally heard positive experiences from people who do it, but I'd
still only recommend it if you actually *need* the newer kernel, e.g. for
hardware support.

You don't get security updates for backport kernels, so I'd strongly
oppose it if you're running an exposed server.  But for a desktop system
in a normal kind of setup (behind a firewall, or on a private network)
it should be within reasonable expectations of security.

Re: Increasing "time" command precision

[Greg Wooledge]

On Thu, Aug 08, 2024 at 15:08:33 +0200, Franco Martelli wrote:
> The Bash's shell keyword "time" it could be fine, but I don't know how to
> redirect its output to a file (-o switch of /usr/bin/time).

https://mywiki.wooledge.org/BashFAQ/032

Re: Increasing "time" command precision

[Greg Wooledge]

On Thu, Aug 08, 2024 at 08:31:10 +0200, Thomas Schmitt wrote:
> Greg Wooledge wrote:
> >  * TIMEFORMAT=... time foo   will invoke /usr/bin/time, but
> >TIMEFORMAT=... eval time foo  will use the builtin.

(Yeah, oops, time is a "shell keyword", not a "builtin".)

> I wonder about the formal reason for this.
> 
> Is it because "time" is not listed in the man page under
> SHELL BUILTIN COMMANDS but mentioned as "reserved word" under Pipelines ?
> Does the variable assignment before "time" cause the rest of the line
> to be regarded as Simple Command rather than as Pipeline ?

There are some mysteries in bash that I'm content simply to write off as
"here be magic".  I note that such mysteries exist, I try to find the
best workarounds that I can, and I document them if I feel other users
are likely to find my workarounds helpful.

Honestly, I don't fully know.  You could ask on the help-bash mailing
list, if you really want to find out.  Or go source-diving in bash
yourself.  But I suspect it's simply that the grammar for "time" was
never extended to allow temporary variable assignments.

Shell keywords (such as "time", and also "if", "while", "case", "[["
and several others) have special grammar/parsing rules.  If one of these
keywords is involved, you're no longer looking at a Simple Command.
You've got something different.

In the specific case of "time", the syntax is

time [-p] pipeline

If your code says

time echo hi | sleep 2

then you aren't simply timing the echo command.  You're timing the whole
*pipeline*, including the sleep command.  This wouldn't be possible
without "time" flexing its keyword powers and bending the parsing rules.
You can't do that with /usr/bin/time, unless you invoke a whole new shell:

/usr/bin/time sh -c 'echo hi | sleep 2'

which of course distorts your timing.  (Also note that "time echo" runs
the shell's builtin echo, while "/usr/bin/time echo" would be forced
to run /usr/bin/echo, since /usr/bin/time doesn't have access to the
shell's builtins.)

Re: Increasing "time" command precision

[Greg Wooledge]

On Wed, Aug 07, 2024 at 22:15:00 +0200, Thomas Schmitt wrote:
> it turns out that TIMEFORMAT belongs to the bash builtin "time"
> and that digit precision numbers only up to 3 are obeyed.
> 
>   $ export TIMEFORMAT="r=%7R
>   u=%4U
>   s=%1S"
>   $ time echo
> 
>   r=0.000
>   u=0.000
>   s=0.0

Just for the record:

 * You can use the $'...' quoting form in bash, to put newlines in
   a string value using \n.

 * TIMEFORMAT=... time foo   will invoke /usr/bin/time, but
   TIMEFORMAT=... eval time foo  will use the builtin.

hobbit:~$ TIMEFORMAT=$'real %R\nuser %U\nsys %S' eval time sleep 0.2
real 0.202
user 0.002
sys 0.001

Re: Authenticator apps

[Greg Wooledge]

On Sun, Aug 04, 2024 at 19:57:22 +0200, to...@tuxteam.de wrote:
> I don't know what an "authenticator app" is.

I don't either, but I have to use one at work.

https://support.microsoft.com/en-us/account-billing/about-microsoft-authenticator-9783c865-0308-42fb-a519-8cf666fe0acc

I have no idea what it is, but it's installed on my work-issued phone,
and I have to use it occasionally when I sign in to certain web apps
on my work-issued laptop.

On the days where the web app decides it hasn't talked to Microsoft
Authenticator recently enough, I have to go get my phone, type the
passcode once to unlock it, click the Authenticator icon and type my
passcode a second time to launch the app, then type my passcode a
third time inside the app to validate that yes, I am the person trying
to open the web page.  I think there's a two-digit number that I have to
type as well.

I cannot imagine how installing one of these things on your Linux PC
is going to help you.  Either you're dealing with a workplace-enforced
authentication setup, in which case you need to use whatever authenticator
*they* chose... or you're trying to establish some sort of "two factor
authentication" of your own, in which case, having both factors be
"I'm logged into my Linux account" kinda defeats the purpose.

Re: nsswitch what should come first

[Greg Wooledge]

On Fri, Aug 02, 2024 at 10:29:40 -0400, gene heskett wrote:
> ISP's dns. I suppose eventually they'll issue
> .den and I be forced to pick some other 3 letter name for my local domain.

https://www.hostzealot.com/domains/den

Re: switch users and still use display

[Greg Wooledge]

On Fri, Aug 02, 2024 at 11:35:58 +0200, Florent Rougon wrote:
> Which I am inclined to believe, although I'm reluctant to try 'su -p'
> for fear of creating a mess in my normal user setup:
> 
>   ~ % su -p
>   Password:
>   zsh compinit: insecure directories and files, run compaudit for list.
>   Ignore insecure directories and files and continue [y] or abort compinit 
> [n]? ^C

I don't use zsh, so I don't quite understand what "compinit" means.
But, just looking at the su(1) man page:

   -m, -p, --preserve-environment
   Preserve the entire environment, i.e., do not set HOME, SHELL, USER
   or LOGNAME. This option is ignored if the option --login is
   specified.

The main issue here is likely to be the HOME variable.  If you're running
a shell as root, but with HOME=/home/florent or whatever, then some of
the programs you start may create new dot files inside /home/florent/.
These files will be owned by root (because the programs are running as
root).  Then, at some point in the future, if you run those same programs
as florent, you won't be able to change the contents of the dot files.
(You would, however, be able to remove them.)

That's not a security hole or anything like that, but it might cause some
surprises.

A secondary issue might be the mismatch between the effective UID (0)
of the programs you run, and the LOGNAME/USER variables (florent).  Some
programs may act upon one, and some may act upon the other.  Some may
even create a strange mixture of both.  I don't have any specific examples
of this.

Realistically, what one *wants* from su is for it to override the HOME,
PATH, USER and LOGNAME variables.  The version of su in Debian prior to
buster used to do that, and everything was peachy.  The version of su in
buster and beyond no longer sets PATH by default.  However, you can fix
that!  All you have to do is create a one-line configuration file:

hobbit:~$ cat /etc/default/su
ALWAYS_SET_PATH yes

Then the buster+ version of su will behave sensibly, changing the PATH
variable to a standard one which includes /usr/sbin and so on when you
become root.

Re: nsswitch what should come first

[Greg Wooledge]

On Thu, Aug 01, 2024 at 14:47:49 +, fxkl4...@protonmail.com wrote:
> i have mysql on host1
> i created a user for mysql so i could have access from 192.168.1.%
> that works fine
> on host2 i use "mysql -u user1 -p --host=host1" and it works
> if on host1 i use "mysql -u user1 -p --host=host1" it fails
> ERROR 1045 (28000): Access denied for user 'user1'@'localhost' (using 
> password: YES)
> in /etc/hosts i have "127.0.1.1 host1.my-network host1"
> if i comment this line out, accessing mysql from host1 works

Take one more step back:

Do you have a local area network, with two or more hosts on it, and does
each of those hosts have an assigned IP address?

I.e. is host1 *always* 192.168.1.5?

If that's the case, then the correct fix is to change the 127.0.1.1 line,
replacing 127.0.1.1 with the assigned IP address (192.168.1.5 or whatever
it is).

The 127.0.1.1 is a fallback for systems where the IP address isn't fixed.
It guarantees that your system will be able to look up its own hostname
and get *some* kind of working IP address.  But if you have a fixed IP
address, you should use that instead.

If your hosts are getting their IP addresses by DHCP, and you'd like them
to get the same address every time so that you *can* make this change to
your /etc/hosts files, then you'll want to tell your DHCP server to assign
a fixed IP address to each MAC address.

Re: systemd may silently break your system!

[Greg Wooledge]

On Thu, Aug 01, 2024 at 16:03:32 +0200, Vincent Lefevre wrote:
> so the silent breakage was known and done on purpose.

... OK, you're just living in a personal fantasy.  There's nothing more
to be gained by trying to interact with you on this topic, so I'm going
to stop now.

Re: nsswitch what should come first

[Greg Wooledge]

On Thu, Aug 01, 2024 at 14:30:05 +, fxkl4...@protonmail.com wrote:
> my nsswitch.conf is "hosts: files mdns4_minimal [NOTFOUND=return] dns"
> i don't remenber changing it in the past few decades
> i recently had a situation that made me question the ordering
> my dns server is my primary router
> should dns be first

It would be *extremely* unusual to want to consult DNS before /etc/hosts.
I recommend leaving files first unless you have a *really* good reason
to switch them.

I have no comment on mdns4_minimal because I don't really know what that
is.

Re: systemd may silently break your system!

[Greg Wooledge]

On Thu, Aug 01, 2024 at 14:47:16 +0200, Vincent Lefevre wrote:
> No, even for unstable, maintainers should ensure that packages are
> upgraded in the right order.

Once again, here is my understanding of the current situation:

 1) A new procps package was uploaded, which no longer has /etc/sysctl.conf.

 2) A new systemd package was uploaded, which removes the now-dangling
/etc/sysctl.d/99-whatever symlink.

 3) It was discovered that the new procps package fails to remove the
existing /etc/sysctl.conf file when upgrading.  This was filed as
a bug, and will be fixed at some point.

I see NO reason to point fingers of blame at systemd (cf. Subject:).

I see nothing amiss here in the order in which packages were uploaded.

I see NO reason that these two packages have to be upgraded in a specific
order (cf. quoted text).  Once the procps bug is fixed, upgrading EITHER
of the two packages will cause the /etc/sysctl.conf to stop being used.
It doesn't MATTER which one is upgraded first.

What exactly is your problem right now?  What part of this quite natural
unstable change process has you SO ENRAGED that you keep posting over
and over to this thread?  I really can't see it.

Are you angry because your system still has a file that it's not supposed
to have, even though nothing reads that file any longer?

Please get over it.  If having an unused file present INFURIATES you,
just remove the stupid file already.

Re: Debian Sid. General questions.

[Greg Wooledge]

On Tue, Jul 30, 2024 at 19:54:49 +0500, 타토카 wrote:
> "Debian *does* use git snapshots and other pre-releases for some packages,
> but not for Firefox ESR." - What do you mean?

For example, the package xserver-xorg-video-intel in bookworm has
version 2:2.99.917+git20210115-1

Re: Debian Sid. General questions.

[Greg Wooledge]

On Tue, Jul 30, 2024 at 14:53:39 +0100, Joe wrote:
> As far as I
> know, Debian doesn't use beta versions of any software, even in
> unstable, so Firefox itself in unstable is likely to be the same
> Firefox downloaded by thousands of people using other distributions,
> and is no more likely to fail in unstable than anywhere else.

Debian *does* use git snapshots and other pre-releases for some packages,
but not for Firefox ESR.

Firefox ESR is taken from the closest thing there is in this world to
an upstream stable release series for a major web browser.  I would
worry less about the firefox-esr package in unstable than pretty much
*any* other package, when it comes to upstream bugs.

Re: Debian Sid. General questions.

[Greg Wooledge]

On Mon, Jul 29, 2024 at 20:26:00 +0500, 타토카 wrote:
> If I want to use rescue mode for debian via netinst, will my pc have to
> have an internet connection? Yea, it is a stupid question, but anyway.

No, you do not need an internet connection to boot the netinst image.
Not even to install from it (though it's strongly recommended).

You could, in theory, install from the netinst image on a non-networked
PC and just have the bare Debian "Standard" installation (no desktop
environments).  In fact, some people prefer installing this way.

As a rescue image, the Debian installer (netinst or larger) tends to be
missing a lot of tools that you might want.  You can usually get what
you need done, but it might take several tries to find fallback tools
when your expected tools are not there.

But no, you don't need Internet.

Re: Tool to store on IMAP server

[Greg Wooledge]

On Mon, Jul 29, 2024 at 16:23:14 +0200, Nicolas George wrote:
> I want: transfer ONE message to an IMAP account.
> 
Then use the mutt solution.

> And mutt's behavior is too unpredictable to be used in a non-interactive
> way.

You did not say you wanted to do this NON-INTERACTIVELY.

Why do you want to do it non-interactively?  It's ONE MESSAGE, ONE TIME!

Just do it interactively, and you're done.  Problem solved.

...

Can anyone guess what my next response is going to be?  I have a guess.
It will involve the letters X and Y.

Re: Tool to store on IMAP server

[Greg Wooledge]

On Mon, Jul 29, 2024 at 16:09:16 +0200, Nicolas George wrote:
> mick.crane (12024-07-29):
> > > I am looking for a tool that reads a mail from its input and stores it
> > > into an IMAP mailbox:
> > With a new Dovecot install
> 
> Thanks, but this is not at all what I am asking. Dovecot is the server,
> I am asking for a client.

https://superuser.com/questions/191719/transferring-lots-of-messages-between-imap-accounts

Re: Upgrading systemd may silently break your Unstable/Sid system!

[Greg Wooledge]

On Mon, Jul 29, 2024 at 01:13:10 +0200, Vincent Lefevre wrote:
> On 2024-07-28 14:13:09 +, Michael Kjörling wrote:
> > And posting on debian-user with a bombastic Subject line which implies
> > that this is a widespread issue when it really only seems to exist in
> > Unstable is, quite frankly, in my opinion at best dishonest.
> 
> No, the breakage was done *on purpose* (together with the lack
> of announcement).

All I can tell you is that you should post bug reports on things that
you believe are broken.  (Yes, I know you've already made some.  If there
are more issues that you feel are not addressed, then maybe you should
post more.)

Ranting on debian-user is extremely unlikely to get anything changed.
You might warn other users that there's an issue, which can be a great
service to the community, but having done that already, continuing to
harp on the same issue repeatedly seems less than productive.

In the interests of posting something *useful*, here's a timeline.
As I understand it, here's what's happened so far:

2024-06-23: bug #1074156 filed against package procps
procps: Depend or Recommend linux-sysctl-defaults
Bug fixed by upload, closed.

2024-07-11: procps (unstable) upload: /etc/sysctl.conf is "removed"
(but not when upgrading)
Closes #1074156

2024-07-12: bug #1076190 filed against package systemd
Installs dangling symlink /etc/sysctl.d/99-sysctl.conf
Bug fixed by upload, closed.

2024-07-24: systemd (unstable) upload: /etc/sysctl.d/99-sysctl.conf
symlink is removed (for upgrades also)
Closes #1076190

2024-07-26: this thread is started on debian-user

2024-07-26: bug #1077184 filed against package systemd
systemd: /etc/sysctl.conf is no longer read
Bug marked as wontfix, closed.

2024-07-26: bug #1077187 filed against package procps
procps: please drop/replace the obsolete sysctl.conf(5) man page
Still open.

Re: Strange behavior of ifupdown package

[Greg Wooledge]

On Sun, Jul 28, 2024 at 19:08:58 +, MailGuard01 wrote:
> Is it still reasonable to add my experience to existing bug report, 
> or should I submit a new one instead? 

Adding to an existing bug report is a good thing, especially if you can
bring new insights, new examples, etc.

Re: systemd may silently break your system!

[Greg Wooledge]

On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote:
> More or less. In the systemd case, for each file, either one chooses
> it, i.e. one has all the current defaults, or one chooses to provide
> a replacement under /etc, i.e. one entirely replaces the defaults by
> one's own settings. An include mechanism would allow a finer control
> of the settings. The sysctl.d configuration system does not allow one
> to include a file (to get the current defaults and possibly change
> some of them just after).

I really don't understand what you're asking for here.

There are defaults in /usr/lib/sysctl.d/*.conf (which is documented
in sysctl.d(5) even in bookworm).  The files in /etc/sysctl.d/*.conf
will override those defaults.

   Configuration files are read from directories in /etc/, /run/,
   /usr/local/lib/, and /lib/, in order of precedence, as listed in the
   SYNOPSIS section above. Files must have the ".conf" extension. Files in
   /etc/ override files with the same name in /run/, /usr/local/lib/, and
   /lib/. Files in /run/ override files with the same name under /usr/.

Why do you need to see the literal word "include" in some other file?
What benefit does that give you?

Re: bash history

[Greg Wooledge]

On Sun, Jul 28, 2024 at 02:01:04 +0100, mick.crane wrote:
> On 2024-07-27 23:58, Greg Wooledge wrote:
> > You need to specify *exactly* what you're doing.

> Sometimes I forget where I was after closing a virtual terminal  and it
> would be handy to see the history
> in a new terminal, where I "cd'd" to for example.
> stuff like that.

No, I mean *how did you close the terminal*?  And what terminal is it?

In the ideal scenario, if you closed the terminal by pressing Ctrl-D
in the shell, the history should be written to disk.  Then, opening a
new terminal+shell should read that history into memory.  You should be
able to search the previous shell's history in that new shell.

There are lots of ways this could fail.  For example, you might be
closing the terminal window by using a window manager control button,
or by running the xkill(1) program and then clicking the window.

Or, you might have too many history lines in memory at the time you
exit the shell, and the cd command that you wanted to find might be
dropped because it was too far in the past.  (Bash only stores 500
lines of history by default.)

Re: systemd may silently break your system!

[Greg Wooledge]

On Sun, Jul 28, 2024 at 01:04:14 +0200, Vincent Lefevre wrote:
> On 2024-07-27 10:23:01 +0200, Michel Verdier wrote:
> > /etc/sysctl.d/README.sysctl recommends to use a separate file such as
> > /etc/sysctl.d/local.conf
> 
> No, it does *not* recommend anything:
> 
> 
> Files located in this directory can set kernel parameters using the
> sysctl(8) or systemd-sysctl(8) tool which is typically run with a
> unit/init file started during the boot sequence.
> 
> For details regarding the configuration files refer to
> sysctl.d(5) or sysctl.conf(5)
> 

You're on unstable.  In bookworm, it says this:


Kernel system variables configuration files

Files found under the /etc/sysctl.d directory that end with .conf are
parsed within sysctl(8) at boot time.  If you want to set kernel variables
you can either edit /etc/sysctl.conf or make a new file.

The filename isn't important, but don't make it a package name as it may clash
with something the package builder needs later. It must end with .conf though.

My personal preference would be for local system settings to go into
/etc/sysctl.d/local.conf but as long as you follow the rules for the names
of the file, anything will work. See sysctl.conf(8) man page for details
of the format.

After making any changes, please run "service procps force-reload" (or, from
a Debian package maintainer script "deb-systemd-invoke restart procps.service").


(Wrong section number, too.)

Bear in mind that the overwhelming majority of users reading this
mailing list are on stable or older.  Most of us have no idea what
unstable looks like, unless you tell us.

> Worse, it refers to the sysctl.conf(5) man page, which lists
> /etc/sysctl.conf as the possible files:

Agreed -- that should be changed.  I think there's a bug report opened
for that already...?  Yes, it's one of yours:

https://bugs.debian.org/1077187


On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote:
> The configuration got broken by a *systemd* upgrade:
> 
>   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> /etc/sysctl.conf (Closes: #1076190)

The systemd change was only done because of the procps change.  After
the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink
provided by the systemd package was dangling/broken.  So the systemd
maintainer removed the symlink.

> > As it turns out, it's a combination of the two packages.  In bookworm,
> > /etc/sysctl.conf is a Conffile of the procps package, and
> > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > the systemd package.
> 
> What does a regular file make different compared to a conffile
> concerning its handling?

A conffile is user-managed, so any changes you make to a conffile must
be respected by the package.  It can't just overwrite your changes, or
restore a conffile if you've deleted it.

> > In unstable, apparently, *both* of them are gone.
> 
> No, /etc/sysctl.conf is not gone on existing installations.
> It is just no longer read.

It's... not?  Then what the hell does the procps change text mean?

> > while 
> > 
> >  says:
> > procps (2:4.0.4-5) unstable; urgency=medium
> > 
> >   * Add Recommends: linux-sysctl-defaults Closes: #1074156
> >   * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
> >   * Updated /etc/sysctld.d/README

That sure sounds like it's removed, to me.

> only for *new* installations.

Well... it's a conffile.  If you made any changes to it, then the package
can't just remove it during an upgrade.

I'm not sure what would happen to an unmodified /etc/sysctl.conf file
during an upgrade.  This isn't a common situation.

> There's a bug about it (about existing installations). But the systemd
> change should have been done *after* the future correction of procps
> in order not to break configuration.

Then it's a good thing these changes haven't made their way into a release
yet.  This is what the unstable -> testing -> release process is for.

And thank you for filing bug reports.

Re: bash history

[Greg Wooledge]

On Sat, Jul 27, 2024 at 23:44:08 +0100, mick.crane wrote:
> On 2024-07-27 23:08, Greg Wooledge wrote:
> > On Sat, Jul 27, 2024 at 22:50:17 +0100, mick.crane wrote:
> > > In debian bookworm, xfce desktop, different virtual terminals have a
> > > different history if same user presses "up key" in different virtual
> > > terminals ?
> > 
> > As your subject says, this is "bash history".  And yes, each instance of
> > bash has its own separate history.  It has nothing to do with your
> > terminal emulator or your desktop environment.
> Where is it if not in ~/.bash_history?

Then it's wherever you changed it to.

> > Bash reads its history from a file (~/.bash_history by default) at
> > startup time, manages it in memory while running, and writes it back
> > out to the history file upon exiting.
> 
> Does this separate history get written to ~/.bash_history when terminal
> emulation thing is closed?

You need to specify *exactly* what you're doing.

If you close a terminal emulator in such a way that it kills the shell
without letting the shell write history to disk, then the history will
not be saved.

If you want history to be saved, you should exit from the *shell*
(e.g. by pressing Ctrl-D), rather than closing the terminal and counting
on that to terminate the shell in a way that will preserve history.

If you *don't* want history to be saved, there are many ways to make
that (not) happen, depending on your terminal emulator and so on.  You'll
need to experiment, though, to see exactly what happens when you do
whatever it is you do.

Whenever I need to reboot my computer (kernel update or the like), I
decide which shells I want to retain history from, and I exit from those
cleanly (^D).  I leave the others running, and exit from FVWM, which
kills them in a way that causes their history not to be written.

If you want a particular shell window's history to be AGGRESSIVELY
written to disk every time you run a command, you can arrange for that
as well.  See <https://mywiki.wooledge.org/BashFAQ/088> for example.

Re: SeLinux

[Greg Wooledge]

On Sat, Jul 27, 2024 at 22:40:10 +, Andy Smith wrote:
> Hi,
> 
> On Sun, Jul 28, 2024 at 06:30:50AM +0800, cor...@free.fr wrote:
> > Is selinux necessary in a production environment?
> 
> "Will my door still function as a door if it has no lock on it?"

More like "Will my door still function as a door if it has a lock, but
isn't covered with metal spikes?"

Re: bash history

[Greg Wooledge]

On Sat, Jul 27, 2024 at 22:50:17 +0100, mick.crane wrote:
> In debian bookworm, xfce desktop, different virtual terminals have a
> different history if same user presses "up key" in different virtual
> terminals ?

As your subject says, this is "bash history".  And yes, each instance of
bash has its own separate history.  It has nothing to do with your
terminal emulator or your desktop environment.

Bash reads its history from a file (~/.bash_history by default) at
startup time, manages it in memory while running, and writes it back
out to the history file upon exiting.

> Is this something that can be changed so history is shared between virtual
> terminals?

No.

I consider this a *good* thing, personally.  I used commerical Unix with
ksh for a very long time, and ksh shares history between instances in
real time.  This is a *nightmare*.  I really, really disliked it.

In the worst case scenario, you and a coworker might both be logged in
as root (where root's shell is ksh) simultaneously.  Your histories
would then intermix in real time.  You might press ESC k ENTER in your
terminal, expecting to re-run the command you had just executed a
moment ago, and unexpectedly run your coworker's command.

Even in a "normal" scenario where I'm logged in as myself, and nobody
else has my password, I would not want all of my terminal windows to have
a shared history.  Each of them is doing something different.  I want
each terminal's workflow to be isolated to that terminal and what I'm
doing in it.  I don't want them contaminating each other.

Of course, that's my opinion, and if you want a shared history across
concurrent shell instances, there are probably shells that can do that.
I've never looked for it, because having lived with it, I already know
I don't want it again.

Re: switch users and still use display

[Greg Wooledge]

On Sat, Jul 27, 2024 at 16:43:50 +, fxkl4...@protonmail.com wrote:
> simple is better
> thanks
> 
> does ssh destinguish between "ssh host1" and "ssh localhost"

Depends on how everything is configured.  It can.

If you prefer 'ssh -X user2@host1' and if that works for you, then you
can use that.

You're over-thinking this, I suspect.

Re: switch users and still use display

[Greg Wooledge]

On Sat, Jul 27, 2024 at 15:44:51 +, fxkl4...@protonmail.com wrote:
> i log in to x session as user1 on host1
> from within a xterm i want to change to user2 on host1 and run x programs
> the current way i do this is ssh user2@host1

I'm assuming you mean "ssh -X", or that you've configured the ssh command
to use this option automatically.  This is a perfectly good way to do it.

> does using ssh on the same host use encryption

Yes.

> is there another way to do this

Yes, but the other ways are *far* more complicated, especially when
neither user1 nor user2 is root.  The issue is that in order to
authenticate yourself to the X server, you present a token, known as
a "magic cookie".  Your magic cookie is stored in a file in your home
directory, which by default only you can read.  All of the programs
that you run as yourself can read this file and therefore present
the magic cookie on demand.

If user2 is root, you can set an environment variable so that root reads
your magic cookie file, because root can (typically) read every file on
the system.

However, when user2 is *not* root, it has no way to read your magic
cookie.  So you need to arrange for some means of conveying this token
to the second user account.  None of them are simple.

You're really better off just continuing to use ssh -X user2@localhost.
It does exactly what you want.

Re: systemd may silently break your system!

[Greg Wooledge]

> On 2024-07-26, Vincent Lefevre wrote:
> 
> > The /etc/sysctl.d/99-sysctl.conf symlink has been removed
> > (currently in unstable) *without any announcement*, so that
> > the /etc/sysctl.conf file (which is still documented, BTW)
> > is no longer read.
> >
> > So, be careful if you have important settings there (security...).

I kept wondering: what does this have to do with the Subject
header?  The files in question belong to the procps package, not
to systemd, right?

As it turns out, it's a combination of the two packages.  In bookworm,
/etc/sysctl.conf is a Conffile of the procps package, and
/etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
the systemd package.

In unstable, apparently, *both* of them are gone.


 says:
  [ Luca Boccassi ]
  * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)

while 

 says:
procps (2:4.0.4-5) unstable; urgency=medium

  * Add Recommends: linux-sysctl-defaults Closes: #1074156
  * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
  * Updated /etc/sysctld.d/README

So it seems to have been a removal performed at the whim of the procps
maintainer.  Perhaps there was discussion somewhere amongst the developers
that I'm not aware of.

It does seem like the sort of change that would belong in the NEWS
file, but I don't see it in
.

Re: Ente Auth

[Greg Wooledge]

On Fri, Jul 26, 2024 at 10:56:11 -0400, e...@gmx.us wrote:
> On 7/26/24 09:31, Mick Ab wrote:
> > 
> > I found ente_auth@ in both /bin and /usr/bin
> > 
> > I thought I needed to run this in order to launch ente-auth, so typed
> > ente_auth@ but my system said the command could not be found.
> > 
> > Any suggestion as to what I am doing wrong, please ?
> 
> The @ suffix is ls's way of indicating that the "file" in question is
> actually a soft link.  Run "ls -l /bin/ente_auth /usr/bin/ente_auth" to see
> what they point to.  Yes there are other commands that'll also work.

While you're at it, check out:

ls -ld /bin /usr/bin

Re: combine two commands via pipe

[Greg Wooledge]

On Fri, Jul 26, 2024 at 09:44:52 +0700, Max Nikulin wrote:
> https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_.2A.mp3.29
> for f in $(ls *.mp3)
> No 1 in Bash Pitfalls

I added nicer anchors, which you can use if you prefer:

https://mywiki.wooledge.org/BashPitfalls#pf1

The auto-generated anchor also works, of course, but is far less pleasing
to read.

This particular pitfall isn't an exact match for the OP's situation,
but it's tangentially related.  The OP is explicitly insisting that
the /tmp directory will always and forever have exactly one entry
containing "apache" in its name.  This is a poor assumption; *anyone*
can make another file or subdirectory in /tmp, and they could put
the word apache in its name.

Therefore, it's possible that $(ls /tmp | grep apache) might return
more than one result.  This will break the OP's "/tmp/$(ls ...)"
solution.  The glob alternative will still work, however.

So, in summary, the glob solution:

 * Is shorter.
 * Is easier to read and understand.
 * Is more efficient.
 * Doesn't break if someone creates /tmp/apache420.

Re: combine two commands via pipe

[Greg Wooledge]

On Fri, Jul 26, 2024 at 10:00:48 +0800, cor...@free.fr wrote:
> I found this works though it's ugly.
> 
> $ sudo ls -ltr "/tmp/$(ls /tmp |grep apache)"
> total 4

Just use a glob.

sudo ls -ltr /tmp/*apache*

Re: combine two commands via pipe

[Greg Wooledge]

On Fri, Jul 26, 2024 at 07:59:42 +0800, cor...@free.fr wrote:
> 
> > 
> > I won't go any fancier than this until I know it's actually needed.
> 
> My actual requirement is that I want to 'ls -ltr' into a subdir in /tmp.
> that subdir is apache's tmp dir. but the name of the subdir is too long
> (hard to copy&paste), so I am looking for a easier way.

Then how do you KNOW which subdirectory to use?

Is it the only one with "-apache" in its name?  If so:

ls -ltr /tmp/*-apache*

Otherwise, please describe how you (as a human with a mind) know which
directory it is.  Then we can try to duplicate that reasoning feat
with commands.

Re: combine two commands via pipe

[Greg Wooledge]

On Fri, Jul 26, 2024 at 07:29:10 +0800, cor...@free.fr wrote:
> On 2024-07-26 07:14, Alain D D Williams wrote:
> > Neither do you say what you are trying to achieve. Looking for files
> > owned by
> > apache in a directory ?
> 
> yes.

Does "owned by apache" mean literally the user "apache"?  Or is it really
the user "www-data"?

I'm going to assume you mean www-data.

This will give you the file and directory names:

find /tmp -user www-data

If you want more detail, add -ls to the end:

find /tmp -user www-data -ls

If you want the output to be sorted by the real ls(1), you have to
get a bit fancier.  Here's one way, but it relies on the number of
pathnames being relatively small:

find /tmp -user www-data -print0 | xargs -0 ls -ldtr

If there are too many results, ls will be executed multiple times, and
then you'll get a series of separately sorted chunks, all concatenated
together.

I won't go any fancier than this until I know it's actually needed.

Re: Trouble when editing a Debian wiki page

[Greg Wooledge]

On Thu, Jul 25, 2024 at 20:02:11 +0700, Max Nikulin wrote:
> On 25/07/2024 19:11, Greg Wooledge wrote:
> > On Thu, Jul 25, 2024 at 18:54:38 +0700, Max Nikulin wrote:
> > > https://wiki.debian.org/EnvironmentVariables?action=recall&rev=32
> [...]
> > I can't quite guess what "text has no left margin" means here.
> 
> Firefox-115, see the attachment. Notice that "General", unlike table of
> contents, is not separated from window border by 52px margin.

Yeah... I have to use a Private window (Firefox) or an Incognito window
(Chrome) to duplicate this.  If I'm using my regular browser sessions
where I'm logged in to the wiki, I don't get that result.

Re: Trouble when editing a Debian wiki page

[Greg Wooledge]

On Thu, Jul 25, 2024 at 18:54:38 +0700, Max Nikulin wrote:
> A space before " <>" combined with 2 empty lines after
> cause extra "" closing  before following text. So
> most of article text has no left margin.
> 
> https://wiki.debian.org/WikiSandBox?action=recall&rev=144
> https://wiki.debian.org/EnvironmentVariables?action=recall&rev=32

So, a bug in MoinMoin -- not a huge shock.

But y'all are still seeing something other than what I'm seeing.  I guess
my browsers are just ignoring the invalid HTML and giving me a page that
looks fine, while some of you are seeing... I don't know what.  I can't
quite guess what "text has no left margin" means here.

Oh -- if I do it in a Chrome Incognito window, I get different results.

So, I guess being logged in to the wiki changes the HTML just enough to
work around the bugs, to the point where most editors aren't aware that
there *is* a bug, because we're all logged in.  Or there's something
else in my normal browser environment, which is absent in Incognito,
which works around this particular bug.

Weird.

Re: Trouble when editing a Debian wiki page

[Greg Wooledge]

On Thu, Jul 25, 2024 at 09:50:43 +0700, Max Nikulin wrote:
> https://wiki.debian.org/EnvironmentVariables?action=raw&rev=33
> 
> has one empty line after "<>" while rev=22 has 2 empty
> lines and it may be more significant than a space before  "<<".

I assume you mean "while rev=32".  I removed the extra blank line at
the same time I removed the leading space.  The leading space causes
indentation, but a blank line should just be ignored when rendering
the HTML.  It has no significance in the final appearance.

> The Permissions article has an extra space in the translations line causing
> extra indentation due to rather weird markup
> 
>   

I don't touch the translation stuff.  Whatever the Debian translation team
wants to do, I let them do it.  If the wiki markup for the translations
table is broken, someone on that team will have to be the one to fix it.

I feel sympathy for anyone who's trying to translate a wiki page that
keeps changing.  I can only imagine how much effort that must be.

I suspect that part of the reason the Debian wiki doesn't get updated as
often as it probably should is because people don't want to create extra
work for the translators.

Re: Trouble when editing a Debian wiki page

[Greg Wooledge]

On Wed, Jul 24, 2024 at 20:08:08 +0200, Franco Martelli wrote:
> On 24/07/24 at 15:34, Greg Wooledge wrote:
> > > Could anybody tell me what I did wrong?
> > You had a leading space before the << tag.  That caused the TOC to be
> > indented.  I removed that.
> 
> Oh, Thank you very much Greg, what confused me it was the page that I took
> as reference:
> 
> https://wiki.debian.org/Permissions?action=raw
> 
> here there's a space before the << tag and, as I said, clicking on the
> "Preview" button when in edit mode, it didn't help.

Well, the table of contents is indented on that page as well.

It sounds like you're ... not seeing what I'm seeing, though.  I checked
in both Chrome and Firefox, and everything looks fine, assuming you
don't mind the TOC being indented.

Are you seeing something *else*?  In what browser?

Re: Maybe off topic: Where is bash gesture ${X=Y} described ?

[Greg Wooledge]

On Wed, Jul 24, 2024 at 15:33:11 +0200, Thomas Schmitt wrote:
> GRUB's test scripts often show this gesture
> 
>   : "${TMPDIR=/tmp}"
> 
> Well known and described is
>   ${X:=Y}
> which assigns a default value to variable X if it is empty (man bash
> says: "If [...] unset or null").
> Also known and described is ":", the no-op command.
> So
>   : "${TMPDIR:=/tmp}"
> would not be a riddle. But "=" instead ":=" causes a subtle change in
> behavior. A defined but empty variable does not get the default content:


$ man bash
[...]
   Parameter Expansion
   [...]
   When not performing substring expansion, using the forms documented be‐
   low  (e.g.,  :-),  bash  tests  for  a parameter that is unset or null.
   Omitting the colon results in a test only for a parameter that  is  un‐
   set.

   ${parameter:-word}
  Use  Default  Values. [...]


Everyone skips over the sentence that begins with "Omitting the colon".

Every time we try to tell Chet, "Hey, man, please add examples that
show BOTH syntaxes", he blows us off, because this is the way POSIX
documents it.  If it's good enough for POSIX, then it must be good
enough for bash, right?[1]

Ordinary users search for the SYNTAX.  Then when they find a list of
examples, they only read that list.  They don't read the text BEFORE
the list.  They might read text AFTER the list, but even that's rare.

This is why I created .
You can look up syntax there and see what it does.


[1]Hmm, it looks like POSIX added a table:
   

   actually shows both forms, if you scroll down a bit.

Re: Trouble when editing a Debian wiki page

[Greg Wooledge]

On Wed, Jul 24, 2024 at 15:19:29 +0200, Franco Martelli wrote:
> https://wiki.debian.org/EnvironmentVariables
> 
> The trouble is that the page has lost indentation, the text begins on the
> left side of the page.

The only part that was indented was the table of contents itself.  I
fixed that.

> Could anybody tell me what I did wrong?

You had a leading space before the << tag.  That caused the TOC to be
indented.  I removed that.

Re: How to update environment variable output

[Greg Wooledge]

On Wed, Jul 24, 2024 at 21:08:29 +1000, Keith Bainbridge wrote:
> So when I opened my xterm this morning, I saw:
>  keith@lenv0
> 
>  Tue 23Jul2024@19:19:30 205.2024 AEST
>  :~   $>
> 
> You have new mail in /var/spool/mail/keith
> 
> 
> Pressed enter, and the day# updated:
> 
>  keith@lenv0
> 
>  Wed 24Jul2024@09:48:36 206.2024 AEST
>  :~   $>

Please tell us *exactly* what "opened my xterm this morning" means.
Did you run a new instance of xterm?  Did you un-minimize an existing
instance?

Are you using a persistent tmux or screen session?

Here are a few commands whose output might be helpful:

declare -p PS0 PS1 PROMPT_COMMAND
ps -fp $PPID
trap DEBUG
PS4='+ $BASH_SOURCE:$FUNCNAME:$LINENO:' bash -ixc : 2>&1 | grep YEAR
PS4='+ $BASH_SOURCE:$FUNCNAME:$LINENO:' bash -ilxc : 2>&1 | grep YEAR

Re: How to update environment variable output

[Greg Wooledge]

On Tue, Jul 23, 2024 at 13:38:48 -0500, David Wright wrote:
> On Tue 23 Jul 2024 at 09:31:36 (-0400), Greg Wooledge wrote:
> > On Tue, Jul 23, 2024 at 23:22:52 +1000, Keith Bainbridge wrote:
> > > The day# in my command prompt increments when I start in the morning. 
> > > Maybe I need to press enter.
> > 
> > That makes it sound like you're setting the YEAR et al. variables in the
> > PROMPT_COMMAND variable.
> > 
> > If that's the case, it's *less* wrong, but only a little bit.  You still
> > have the issue that the date might change while you're sitting at a
> > stale shell prompt from yesterday, with stale date/time variables.
> 
> Actually, that is what I do want (the time—the date not so much).
> That tells you when the last command finished. Press Return before
> you start a command and you get some idea of how long it takes
> to run. For the current time, press Return.
> 
> I think putting the time±date in one's prompt is pretty popular,

Sure.  That's a completely different problem from what Keith is describing,
though.

Putting date/time expansions into your PS1 (prompt) causes the system
time to be retrieved when the prompt is displayed.  The date/time strings
are rendered and displayed, and then not remembered by the shell.

What Keith is doing is storing components of the date/time in variables
at shell startup, and then using them at some unspecified point in
the future to create a directory.  This causes issues when the shell
survives through a day transition (midnight).

Keith's workflow might work well if he rigorously logs out (or at least
closes all shells) every night before midnight, and logs in (or re-opens
his shells) in the morning.  But even then, it's still a questionable
implementation.  Anything that relies on a human being to remember to
do something is eventually going to fail.

A safer implementation would retrieve the current date at the moment
when it's needed.  Your PS1 string does this.

Re: How to update environment variable output

[Greg Wooledge]

On Tue, Jul 23, 2024 at 23:22:52 +1000, Keith Bainbridge wrote:
> The day# in my command prompt increments when I start in the morning. Maybe I 
> need to press enter.

That makes it sound like you're setting the YEAR et al. variables in the
PROMPT_COMMAND variable.

If that's the case, it's *less* wrong, but only a little bit.  You still
have the issue that the date might change while you're sitting at a
stale shell prompt from yesterday, with stale date/time variables.

Really, the fundamental problem here is that you should not be storing
date/time information in long-lived variables, and then trying to use
those variables at an indeterminate point in the future.

Anything that needs to act upon the current date should fetch the current
date immediately before acting.

Re: Logs like .xsession-errors, was: fvwm on Debian 12: Modules do not start ...

[Greg Wooledge]

On Tue, Jul 23, 2024 at 14:20:43 +0200, Thomas Schmitt wrote:
> The only helpful match is
> 
>   
> https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text
> 
>   "What Does The Log Say?
>...
>If you're doing something with your window manager or other X client
>programs, then their output probably won't be visible to you
>immediately. The location of their output will depend on how you
>started X. If you used startx(1) from a console, the output probably
>appeared on that console (try Ctrl-Alt-F1 to get back to it, then
>Alt-F7 (usually) to get back to X). If you logged in with xdm(8), then
>xdm creates a file called .xsession-errors in your home directory, and
>you should look there. gdm(8) uses .gnome-errors. The other "*dm"
>programs may have similar files."

There's some outdated info in that paragraph.

In Debian, startx uses /etc/X11/Xsession (among many other files), which
redirects all output to ~/.xsession-errors if it can.

~/.xsession-errors has been the standard place to look for WM and X
client errors for so long that I can't even remember where I first
learned about it.

Also, it's unlikely you'll be able to "get back to" the underlying
console from which you ran startx in a modern version of Debian.  I
want to say... since jessie?  Whenever the big X server changes occurred.

Ever since then, on most systems, the X server runs in the same TTY
where startx was typed, instead of opening a new TTY.  This is actually
really good, security-wise, because it means someone can't walk up to
your machine, press Ctrl-Alt-F1, and then use Ctrl-C or Ctrl-Z to kill
or suspend your X session and get control of your shell.  That used to
be a possibility.

Re: [Solved] vim on Debian 12: How to disable the mouse GUI mode ?

[Greg Wooledge]

On Tue, Jul 23, 2024 at 14:07:04 +0200, Thomas Schmitt wrote:
> Is there a Debian apt-fu which lets me replace "vi" by "rvim" and "view"
> by "rview" ? (So that this PEBKAC cannot fall back to old habits ?)

update-alternatives, or just set up some personal shell aliases.

Re: How to update environment variable output

[Greg Wooledge]

On Tue, Jul 23, 2024 at 18:02:53 +1000, Keith Bainbridge wrote:
> From the tab I had used earlier, ran  source .bashrc
> 
> then
>  :/tmp/205.2024   $>mkcd /tmp/day$DOYR.$YEAR

So you're setting those variables one time inside your .bashrc file?

This is quite bad.  What happens when you have a terminal window that
you open before midnight, and then continue using *after* midnight?
Those variables will still be set to the previous day's values.

Also, why did you start three separate threads for this question?

> So, now question is how can I get cron to 'source .bashrc'I'm thinking
> add that line to my script?

I would advise against it.  Who knows what kind of silly things your
.bashrc may do that you wouldn't want an automated script to pick up.
Even if you verify that your .bashrc is "cron safe" right now, you
might add something to it a year from now, forgetting that you need
it to remain "cron safe", and accidentally break the script.

Any command that's supposed to act based on the current day will need
to perform its *own* request to fetch the current day from the system
clock.  It cannot rely on an environment variable set some unknown
length of time in the past.

Use the date command or bash's printf %()T inside your bash script to
get the current date.

Moreover, never make *two* calls to the system clock in the same script.
If you need the Julian day number (%j) and also the calendar
day-of-the-month number (%d), don't do this:

# WRONG
julian=$(date +%j)
dom=$(date +%d)

That calls out to the system clock twice, and gets two different values.
If the script is executed right at midnight, you might get two different
days.

Instead, only make *one* call.  There are a couple different ways to do
this.  One is to get all the date(1) fields you need at once, and then
parse them out:

read -r julian dom < <(date "+%j %d")

Another is to fetch the epoch time value (%s) and then use that value
in all future calls.  With GNU date:

now=$(date +%s)
julian=$(date -d "@$now" +%j)
dom=$(date -d "@$now" +%d)

Or with bash's printf, on Linux or BSD:

printf -v now '%(%s)T' -1
printf -v julian '%(%j)T' "$now"
printf -v dom '%(%d)T' "$now"

(Bash 5.0 added an EPOCHSECONDS variable as well.)

This same concept applies in any programming language you use.  It's not
just a shell script thing, even though I'm showing shell script examples
here.

Re: Debian Sid. General questions.

[Greg Wooledge]

> > > This particular one may originate from
> > > 

I had forgotten that page even existed.  It hasn't been touched in 16
years.

-rw-r--r-- 1 greg greg 11031 Dec 12  2007 sidfaq.html

At this point it should be considered a historical artifact rather than
a living document.

Re: How to update environment variable output

[Greg Wooledge]

On Tue, Jul 23, 2024 at 17:02:08 +1000, Keith Bainbridge wrote:
> mkcd ()
> {
> mkdir -p $1
> cd $1
> }

You're missing quotes.  Two sets.  You probably also want && between
the two commands, to check for the success of the mkdir before attempting
a cd.

>  in the form  :~   $>   mkcd
> /mnt/data/keith/Documents/$YEAR/$MTH$YEAR/$DOYR.$YEAR/

Where do these variables (YEAR, MTH, DOYR) come from?

> I am transferred to
> /mnt/data/keith/Documents/2024/Jul2024/196.2024   $>ie $DOYR is using
> the wrong day number

How/where did you set it?

> Why is the env var $DOYR not updating when I use it at the command prompt
> AND for that matter in a script - clearly the system is or I'd be getting
> the wrong day # at my command prompt?

We don't know, because you haven't shown us where you're setting it.

> Why am I not getting a warning that the dir already exists?

Because you used mkdir -p.  Please read what -p does.

> I want to run the script as a cron job, to keep a daily copy of a few files
> - mainly to prove that I can do it.

A cron job will not inherit those variables from your shell session,
or wherever it is you're defining them.  You'll have to set them within
the cron job, or use the date(1) command, or use bash's printf %()T
formatter to generate date/time strings.

Re: fvwm on Debian 12: Modules do not start. How to debug ?

[Greg Wooledge]

On Mon, Jul 22, 2024 at 23:09:59 +0200, Thomas Schmitt wrote:
> Four of five fingers point to me and my ~/.fvwm2rc":
> 
>   ModulePath /usr/lib/fvwm/2.6.8
> 
> I see traces that i adjusted this multiple times over the years:
> /usr/lib/X11/fvwm2 , /usr/lib/fvwm/2.6.5 , /usr/lib/fvwm/2.6.8.
> 
> So what's its name this year ?
> 
>   $ find /usr -name FvwmPager
>   /usr/libexec/fvwm2/2.7.0/FvwmPager

Why do you even have that line at all?

hobbit:~/.fvwm$ grep ModulePath *
hobbit:~/.fvwm$ 

What happens if you comment it out?

Re: Debian Sid. General questions.

[Greg Wooledge]

On Mon, Jul 22, 2024 at 21:38:23 +0100, Joe wrote:
> On Tue, 23 Jul 2024 01:27:49 +0500
> 타토카  wrote:
> 
> > I know what PAM is. I understand what the problem is described on the
> > website. But I think if I get Debian Sid Update and after that PAM
> > will crash, I just want to know what the solution can be for it. I am
> > interested in Debian Sid. But I just want to Insure myself of
> > problems, which happened in the past or could happen in the future.
> > 
> >
> There are many things that can break to prevent you using a system. Why
> are you only concerned about PAM? I've had a variety of non-booting
> systems in the past, none of the problems ever involved PAM, most
> involved grub in its early years.

I think the OP is missing the forest for the trees.  (English idiom.  It
means you're getting lost in the details and not seeing the big picture.)

The question isn't just "how do you recover from a broken libpam package
that prevents all logins".  Although that's certainly a question for
which a sid user should have an answer.

Rather, it's "how do you recover from *any* situation where the system
doesn't let you boot and/or log in normally".

And there is no single answer.  It's a question that's supposed to make
you think.  You should be able to come up with something, if you're
going to use unstable.  Obviously, different situational details would
demand slightly different answers.  Or radically different answers.

The point is, you should be able to think of an answer.

If you can't, then running unstable may not be your best choice.

Re: fvwm on Debian 12: Modules do not start. How to debug ?

[Greg Wooledge]

On Mon, Jul 22, 2024 at 21:37:05 +0200, Thomas Schmitt wrote:
> So how could i debug the start of fvwm Modules ?
> Is there any log file or configuration option ?

Error messages, if there are any, should be in ~/.xsession-errors for
most users.  I'd start there.

Re: Debian Sid. General questions.

[Greg Wooledge]

On Tue, Jul 23, 2024 at 00:25:27 +0500, 타토카 wrote:
> I have read on the official Debian website about sid (in russian version):
> "Maybe. There was one real case where PAM broke. PAM checks all users, so
> without PAM no one can login, even as a root. If you work in a precarious
> environment, you must be able to handle such situations.".

It sounds like it was discussing either a real problem that happened
in the past, or a hypothetical problem that *could* happen in the future.

> I don't know how to handle with this situation with PAM. How can I solve
> this problem, when it will be nessesary?

The fact that you can't even tell what the page is talking about is a
sign that you might not want to run an UNSTABLE operating system.

Re: vim on Debian 12: How to disable the mouse GUI mode ?

[Greg Wooledge]

I found a fix:

https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi

Apparently when in an "xterm environment" (whatever that means; apparently
it includes rxvt-unicode), turning on bracketed paste mode works:

:set t_BE=

The = is required.

Re: vim on Debian 12: How to disable the mouse GUI mode ?

[Greg Wooledge]

On Mon, Jul 22, 2024 at 11:23:19 -0400, Justin Piszcz wrote:
> On Mon, Jul 22, 2024 at 11:20 AM Greg Wooledge  wrote:
> >
> > On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:
> > > Since an upgrade from Debian 11 to 12 the vim command
> > >
> > >   :set mouse=
> > >
> > > does not disable the "GUI" interpretation of pasting text or numbers
> > > when vim is in normal mode [...]
> >
> > I'm not sure how you've got it configured, but just having a ~/.vimrc
> > file should be enough to disable the default system vimrc which has all
> > that broken mouse crap.
> >
> > Unless I've got another file somewhere that I've forgotten...?
> >
> 
> Not sure if related to the issue OP is having is the same but I had to
> add this to my ~/.vimrc:
> set mouse=v
> 
> More discussion about the mouse setting here:
> https://unix.stackexchange.com/questions/139578/copy-paste-for-vim-is-not-working-when-mouse-set-mouse-a-is-on

My apologies; my previous message was written hastily.  I didn't actually
test what Thomas was reporting.

Having now tested pasting with the mouse while in command mode, I can
confirm that I get the same behavior Thomas disliked.  It's simply not
something that I normally do, so I didn't notice it.

In my testing, I ran vim with no arguments, and typed in a single line
of gibberish.  Then, I moved the cursor to column 0.  Finally, I typed
out the command 20l in a different terminal, highlighted it, and pasted
it into vim.  Rather than moving my cursor 20 characters to the right,
it inserted the literal string "20l".  Specifically, it acts as if I
had pressed "i20lESC".  I began and ended in command mode, but command
text was inserted as if I had been in insert mode.

Doing :set mouse=v doesn't change this behavior, either.

Neither does any other mouse= mode that I've tried.  Even "mouse=h"
which according to the documentation is supposed to "make the mouse work
in help files only" doesn't fix it.

So, unfortunately I don't have any answers to contribute here.  All I
can give is a weak "me too".

Re: vim on Debian 12: How to disable the mouse GUI mode ?

[Greg Wooledge]

On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:
> Since an upgrade from Debian 11 to 12 the vim command
> 
>   :set mouse=
> 
> does not disable the "GUI" interpretation of pasting text or numbers
> when vim is in normal mode [...]

I'm not sure how you've got it configured, but just having a ~/.vimrc
file should be enough to disable the default system vimrc which has all
that broken mouse crap.

Unless I've got another file somewhere that I've forgotten...?

Re: /var/run disappear after reboot

[Greg Wooledge]

On Mon, Jul 22, 2024 at 20:07:38 +0800, cor...@free.fr wrote:
> I found that after I rebooted the system, the dir /var/run/*** disappeared.
> I put my app's web sessions under /var/run. so they got lost.
> Is there an effective tool to manage /var/run dirs?

hobbit:~$ ls -ld /var/run
lrwxrwxrwx 1 root root 4 Feb 17 12:28 /var/run -> /run/

hobbit:~$ df /run
Filesystem 1K-blocks  Used Available Use% Mounted on
tmpfs1603720  1412   1602308   1% /run

The contents of /run (which /var/run points to) are temporary.
They're only stored in RAM, not on disk.  They are *meant* to go away
at boot time.

If you need to store data permanently, put it somewhere else.

Re: update system periodically

[Greg Wooledge]

On Mon, Jul 22, 2024 at 07:34:29 +0800, Bret Busby wrote:
> One thing to remember, regarding automated upgrades, is that, if an upgrade
> involves a kernel upgrade, then you can have a need for immediate rebooting,
> which may be problematic.

It's also rare, but NOT unheard of, for a stable release to receive a
security update which breaks backward compatibility.  In such cases,
there should be a NEWS file excerpt, which is shown to you by apt or
apt-get, which explains the changes.  You'll want to be aware of any
such changes, which would not be the case with a fully unattended upgrade.

This has happened with samba and bind9, at the very least.

Re: sendmail without DNS

[Greg Wooledge]

On Sun, Jul 21, 2024 at 08:24:06 +0100, Adam Weremczuk wrote:
> Let me rephrase my question, which should be easier to answer.
> 
> What exactly shall I substitute:
> 
> mailer = "/usr/sbin/sendmail -t"
> 
> with in /usr/share/logwatch/default.conf/logwatch.conf
> 
> to make logwatch use postfix (already working without DNS) instead of
> sendmail?

Blimey.  You are COMPLETELY confused, aren't you.

If postfix (the package named "postfix") is installed, and if sendmail
(the package named "sendmail") is NOT installed, then you are using
Postfix to send mail.

Part of the postfix package is a /usr/sbin/sendmail program which
implements the command line interface for local programs to send mail.

EVERY MTA has to implement the /usr/sbin/sendmail program.

Including Postfix.

If you're running Postfix (*not* Sendmail) as your MTA, and if you've
got it configured how you want it, then you are DONE.  You don't need
to ask us how to configure Sendmail to do the same thing, because you're
not USING Sendmail.

Re: Running 32-bit static exeutable on 64-bit Debian

[Greg Wooledge]

On Sat, Jul 20, 2024 at 01:15:22 -0700, Van Snyder wrote:
> > Van Snyder wrote:
> > > And there's still the mystery why a statically-linked executable
> > > wants to
> > > load a shared object library.

https://manpages.debian.org/bookworm/manpages-dev/dlopen.3.en.html

> Am I losing my mind?
> 
> At first I had done "file LinuxSusser". It reported "Statically
> linked."
> 
> Just to be sure, I did the recommended "ldd LinuxSusser." It also
> reported Statically linked."

Then it's almost certainly using dlopen() to load this shared library.

The unpleasant part is that once you install this 32-bit shared lib,
you'll get past this one dlopen() call, and then there might be more
of them.  You'll just have to whittle it down piece by piece until
it stops crashing.  There's no way to get a complete list all at once.

Your testing will also have to try to cover as many code paths as
possible.  Maybe there's a shared lib that only gets read when you
activate a specific feature in the program.  You'll have to try to
test as many features as you can, before you can be reasonably sure
you've got all the libs it will want.

Re: the usage of env

[Greg Wooledge]

On Sat, Jul 20, 2024 at 06:30:42 +0800, p...@gmx.it wrote:
> On 2024-07-20 06:25, Greg Wooledge wrote:
> > > 
> > > I can not clearly understand for this statement. what's "future shell
> > > commands"? can you show an example?
> > 
> > hobbit:~$ unset -v VAR
> > hobbit:~$ VAR=bar; ./a.sh
> > I am a.sh, and inside me, VAR=<>.
> > hobbit:~$ echo "VAR=<$VAR>"
> > VAR=
> 
> OK I know that. $VAR can be seen by future shell command in this
> session, but cannot be seen by a sub-shell such as a.sh.

a.sh is NOT a subshell.  That's really super important.

a.sh is a NON-subshell child process.

In an actual subshell, you *would* see the variable, because subshells
inherit regular variables as well as environment variables.

hobbit:~$ unset -v VAR
hobbit:~$ VAR=foo; (echo "I am a subshell, and VAR=<$VAR>")
I am a subshell, and VAR=
hobbit:~$ ./a.sh
I am a.sh, and inside me, VAR=<>.

https://mywiki.wooledge.org/SubShell

Re: the usage of env

[Greg Wooledge]

On Sat, Jul 20, 2024 at 06:17:46 +0800, p...@gmx.it wrote:
> $ VAR=foo ./a.sh
> i can see VAR=foo

I don't know what "see" means here.

hobbit:~$ cat a.sh
#!/bin/sh
echo "I am a.sh, and inside me, VAR=<$VAR>."
hobbit:~$ unset -v VAR
hobbit:~$ VAR=foo ./a.sh
I am a.sh, and inside me, VAR=.
hobbit:~$ echo "VAR=<$VAR>"
VAR=<>

VAR is defined in the environment of a.sh but NOT in the calling shell.

> > What's the difference between these two commands?
> > VAR3=foo ./a.sh
> > VAR3=bar; ./a.sh
> > 
> > In the first command, VAR3 is placed in the environment of the command
> > being executed.  ./a.sh will see it.  VAR3 will not survive beyond
> > this command.  It will be discarded, and future commands will not be
> > aware it ever existed.
> > 
> > In the second command, VAR3 is created as a regular variable in the
> > current shell, but not exported to the environment.  It will NOT be
> > seen by ./a.sh, but it WILL be seen by future shell commands within
> > this session.
> 
> I can not clearly understand for this statement. what's "future shell
> commands"? can you show an example?

hobbit:~$ unset -v VAR
hobbit:~$ VAR=bar; ./a.sh
I am a.sh, and inside me, VAR=<>.
hobbit:~$ echo "VAR=<$VAR>"
VAR=

Re: the usage of env

[Greg Wooledge]

On Sat, Jul 20, 2024 at 05:46:23 +0800, p...@gmx.it wrote:
> $ VAR1=foo && ./a.sh
> $ export VAR2=foo; ./a.sh
> $ ./b.sh
> 
> 
> $VAR1 will be seen by a.sh only, but $VAR2 can be seen my current login
> session (such as b.sh). Am I right? I am a bit confused about env scope.

If we assume NO other commands have been executed in this shell so far,
then:

VAR1 is not marked for export.  It's just a regular shell variable.
It won't be seen by either call to ./a.sh which is a (non-subshell)
child process, not will it be seen by ./b.sh which is also a non-subshell
child.

VAR2 is marked for export by the interactive shell.  It's a permanent
part of the shell's environment and will be seen by all child processes
from that point forward.

VAR2 will therefore be seen by the second call to ./a.sh and the call
to ./b.sh.

Now, what you didn't ask, but what I *expected* you to ask, is:

What's the difference between these two commands?
VAR3=foo ./a.sh
VAR3=bar; ./a.sh

In the first command, VAR3 is placed in the environment of the command
being executed.  ./a.sh will see it.  VAR3 will not survive beyond
this command.  It will be discarded, and future commands will not be
aware it ever existed.

In the second command, VAR3 is created as a regular variable in the
current shell, but not exported to the environment.  It will NOT be
seen by ./a.sh, but it WILL be seen by future shell commands within
this session.

Re: umask - default user settings?

[Greg Wooledge]

On Fri, Jul 19, 2024 at 23:04:25 +0700, Max Nikulin wrote:
> On 16/07/2024 20:46, Greg Wooledge wrote:
> > On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote:
> > > Now we just need for GNOME users to discover a way to configure the
> > > programs that are started as children of dbus, and then we can move
> > > forward.  Documentation would be my top priority.  If other people want
> > > to try to drum up interest in environment configuration, then there'll
> > > be documentation available for end users to follow.
> > 
> > I've added a bit of content to 
> > <https://wiki.debian.org/EnvironmentVariables>.
> 
> Isn't the following a more suitable article for umask?
> <https://wiki.debian.org/Permissions#Setting_default_umask>
> I think, it is better to drop UMask note from EnvironmentVariables.

I've made some minor changes to both pages.

Re: Remote desktop Debian -> ChromeBook

[Greg Wooledge]

On Fri, Jul 19, 2024 at 15:33:40 +0300, Anssi Saari wrote:
> I've mostly used VNC and x2go for Windows-to-Linux and Linux-to-Linux.
> 
> VNC was and is:
> - Solid and we actually use it at work too.
> - Limited in the number of mouse buttons at some point to five, minor
>   but annoying. At the time I was used to 7.
> - In VNC you run a desktop in the remote end so that needs to be
>   configured and maintained. I'm not a fan of this since it's usually
>   just a small handful of apps I want to run.

You don't *have* to run a full desktop on the remote end.  You can run
a smaller, lighter set of applications if that suits your needs.

At work, I maintain a set of VNC sessions on Linux workstations for remote
Windows users to use.  The workstations themselves have KDE installed,
and if someone's sitting locally in front of the machine, they can login
and use KDE, with all of its bells and whistles.  But for the VNC sessions,
I use fvwm, with a customized menu, and a set of programs that get launched
at session start.

In my experience, the Windows users have been able to adjust to this
quite easily.  After they were told how to open the menu from the
"background", everything else was intuitive.

The only difficult thing was getting copy/paste to work.  I did this by
installing the "autocutsel" package on the workstations, and adding

autocutsel -fork

to the ~/.vnc/xstartup scripts.  Then I added crontabs to launch the VNC
sessions at boot time.  Each user is "assigned" to a specific VNC session,
which is launched with a resolution customized for their monitor(s).  If
they change their monitors and need the VNC session to run at a different
resolution, they contact me, and I work with them to get it changed.  (In
theory they could ssh into the workstation and do it all themselves, if
they knew how.)

It's been working well for us.

Re: the usage of env

[Greg Wooledge]

On Fri, Jul 19, 2024 at 20:12:14 +0800, p...@gmx.it wrote:
> for example, what's the difference between '/usr/bin/perl' and 'env
> perl' ?

"env perl" searches your $PATH.

> I know env may set a environment variable in system, so my question also
> includes:

env is used to *display* the current shell environment, or to set a new
environment for *one* specific process.

E.g.

env FOO=bar ./myprogram

This launches ./myprogram with the additional environment variable FOO
set to the value bar.

> 1. where to see a shell environment variable? I tried 'echo $ENV'
> showing nothing.

Just run env with no arguments.

> the key for perl is "_" in environment variable? under this key, why
> 'env perl' just works?

The _ environment variable is weird.  Please ignore it for now.  You
can live a full and happy life without ever worrying about it.

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Greg Wooledge]

On Thu, Jul 18, 2024 at 13:50:21 -0400, Celejar wrote:
> Really? I had the impression that lots of list subscribers / readers
> run Sid. Are there statistics on this?

Nah, sid users are just louder, on average.  Stable users don't have
as much to talk about, because our stuff just works. ;-)

Re: web site displays blank page

[Greg Wooledge]

On Thu, Jul 18, 2024 at 02:27:39 -0400, Felix Miata wrote:
> Russell L. Harris composed on 2024-07-18 06:06 (UTC):
> > Would someone kindly verify that chewy.com is accessible?
> 
> https://www.chewy.com/ looks normal from FL in Chromium:

Works for me in Google Chrome.

Re: umask - default user settings?

[Greg Wooledge]

On Thu, Jul 18, 2024 at 09:07:48 +0700, Max Nikulin wrote:
> Taking into account a number of bugs, perhaps it is not really bad that
> recipes how to change umask are not easily available. Documentation should
> be extensive enough to describe possible pitfalls.

That's an odd stance, especially if you consider that changing your umask
used to be literally a one-line change.  It still is, if you only use
the shell (locally or remotely).  It still is, if you use a shell login
plus startx plus a traditional window manager.

Even with a Display Manager login and a traditional WM, there are still
just two places you need to change.

It only becomes *hard* when Desktop Environments are introduced into the
picture.

Re: umask - default user settings?

[Greg Wooledge]

On Wed, Jul 17, 2024 at 20:51:40 +0200, Franco Martelli wrote:
> If you plan to add your contribute to the wiki page (see above) in the
> section: "Desktop Environments and systemd user services" e.g.:
> 
> - ...
> - systemctl --user daemon-reload
> - /Restart your Desktop session/
> 
> Please consider also to specify the Desktop you use, because newbies don't
> know nothing about: "Some Desktop Environments launch programs via systemd
> user services." Which Desktop?

Well, that's the problem, isn't it?  *We* don't know either, because
most of us don't use one!

I'm doing the best I can trying to document these systems that I don't
use personally.  It would be *nice* if their developers would document
them, so we wouldn't have to reverse engineer how they work and come up
with our own workarounds.  It's much, much harder when you can't even
reverse engineer one yourself, and instead have to rely on the reports
of other users.

Re: umask - default user settings?

[Greg Wooledge]

On Wed, Jul 17, 2024 at 17:58:57 +0100, Tim Woodall wrote:
> No, I'm talking about sudo, not su. I'm not a sudo user so I can't test
> but my understanding is that root inherits the umask of the invoking
> user (or it used to)

Looks like this is still true.

hobbit:~$ bash
hobbit:~$ umask 077
hobbit:~$ umask
0077
hobbit:~$ sudo -s
[sudo] password for greg: 
root@hobbit:/home/greg# umask
0077
root@hobbit:/home/greg# exit
exit
hobbit:~$ sudo -i
root@hobbit:~# umask
0077
root@hobbit:~# exit
logout
hobbit:~$ sudo bash -c umask
0077
hobbit:~$ umask 022
hobbit:~$ sudo bash -c umask
0022

Re: umask - default user settings?

[Greg Wooledge]

On Wed, Jul 17, 2024 at 22:10:28 +0700, Max Nikulin wrote:
> Do you mean the following bug or something else?
> 
> login: su - doesn't set umask
> Fixed in version pam/1.5.3-1
> Tue, 16 Jan 2024 00:19:23 +

Huh... given the age of the bug, I expected this was something already
done in bookworm, but it's not.

hobbit:/etc/pam.d$ grep -i umask *
hobbit:/etc/pam.d$ grep -i mask *
hobbit:/etc/pam.d$ 

Bookworm has PAM package version 1.5.2-6+deb12u1, not 1.5.3.  Looks like
this change was only made this year, and therefore won't appear until
Debian 13.

This makes me wonder what's setting umask *now*.  Is it still PAM, just
using a compile-time default instead of a value that's discoverable in
a conffile?

Also, this confused me:

hobbit:/etc/pam.d$ dpkg -S /etc/pam.d/common-session
dpkg-query: no path found matching pattern /etc/pam.d/common-session

Where does that file come from, then?  The installer?  Oh wait, there are
postinst scripts

hobbit:~$ grep common-session /var/lib/dpkg/info/*.postinst
/var/lib/dpkg/info/libpam-runtime.postinst: for configfile in common-auth 
common-account common-session  \
/var/lib/dpkg/info/libpam-runtime.postinst:   
"$DPKG_ROOT"/etc/pam.d/common-session.pam-old

So I guess that file comes from libpam-runtime, but it's not managed
like a regular conffile.  I suppose there was some reason for this, even
if I can't guess it.

Re: Debian for Limited memory

[Greg Wooledge]

On Wed, Jul 17, 2024 at 14:36:21 +0800, Jeff Pang wrote:
> I plan to use it for MX backup.
> So the application ram is quite low (postfix consume few resources)

In that case, I'd go for the most recent version of Debian you can
run on whatever kernel you're using.  Hopefully the current stable
release (Debian 12), but you'll need to look into all the details
of your VPS.

Re: LINUX-IMAGE-6.8.11 headers cannot be installed

[Greg Wooledge]

On Tue, Jul 16, 2024 at 19:30:20 -, Prajnanaswaroopa wrote:
> Hello,
> I am using a Kali Linux

https://www.google.com/search?q=kali+linux+support

Re: umask - default user settings?

[Greg Wooledge]

On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote:
> Greg, do you have an example when Environment= in service.d works, but an
> environment.d file does not?

Oh gods, there's MORE shit to worry about??  Of course there is.
Bloody hell.

In previous years, I remember exploring environment.d and discarding it,
because it never achieved the goals that I had in mind.  At that time, I
was trying to find a shell-agnostic and login-style-agnostic way to set
environment variables for all login sessions (console, ssh, DM).

environment.d is not that.

But in this particular investigation, we're "only" trying to find a
way to configure the user environment for programs started by Desktop
Environments.  So, back to the laboratory

Given the existence of the following files:

-rw-r--r-- 1 greg greg 66 Jul 16 11:43 .config/environment.d/foo.conf
-rw-r--r-- 1 greg greg 51 Jul 15 23:24 .config/systemd/user/service.d/env.conf
-rw-r--r-- 1 greg greg 21 Jul 15 23:39 .config/systemd/user/service.d/umask.conf

And given that "systemctl --user daemon-reload" has been performed since
they were last edited, what I'm seeing is that the contents of the
environment.d file are applied *first*, and then the contents of the
service.d files are applied *second*, overriding whatever was in the
environment.d file.

Also, and this is *highly* noteworthy, the syntaxes are different.
In particular, expansions like %h are performed in the service.d files,
but *not* in the environment.d files.

On the other hand, environment.d(5) says you can use a limited subset of
shell expansion syntax.  It might be worth investigating exactly what
variables are available for expansion at that time, but at first glance,
it looks like service.d with its %h is probably going to be more useful.

For anyone reading this in the archives, out of context, please note that
the contents of these files *do not* apply to user logins.  They only
apply to programs started by the systemd --user daemon.