Re: gitification (was Re: /etc/fstab question (problem)?

[Max Nikulin]

On 21/04/2023 00:43, songbird wrote:

Max Nikulin wrote:

On 20/04/2023 19:10, songbird wrote:

one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.


i know what all you've written below but
it does not apply to what i want or how i use those tools
and i consider git broken that it caters to broken tools
and intentionally then has to screw up information which i
consider both useful and critical to how i do things.


Then I have no idea what you were trying to achieve by your original 
message.


It is perfectly valid to warn people that git is not an appropriate tool 
when file attributes audit is involved. I can understand if somebody is 
pushing you toward git. At the same time I see nothing bad in tracking 
config files in git.


If you are looking for a backup tool that keeps metadata then it is 
better to ask it explicitly to to get suggestions like rdiff-backup.


Ignorance may be an excuse, but you said it is not the case. For me it 
is too much to blame developers with harsh statements concerning design 
decisions just because a tool was created for different tasks.


Git appeared as a tool for linux kernel, a project that relies on make. 
Frequent incremental rebuilds are must have for developers. Git has some 
weak sides, but there is no point to attack its features. Git is a great 
step forward in comparison to CVS and SVN. Experiments with version 
control systems and build tools have not seized, likely we will see 
better ones.


Precise tracking of file attributes can cause troubles for VCS. Various 
file systems have different set of attributes, incompatible time 
precision. There is no point to track UIDs at all.


I admit, for reproducible builds that include unprocessed files from 
repository, git behavior is not perfect.


Do not confuse a conscious design choice (even if it is a trade-off) and 
wrong selection of a tool that is inappropriate for specific purpose.



Some build systems make decisions based on file hashes, not their
modification times. It may require a daemon watching file changes to
avoid recalculation of all hashes on each build. So such approach is a
kind of trade-off.


   not a choice i agree with and so i have to work around
it for my purposes.


File hash approach is for developers relying on incremental rebuilds and 
caching of build results. It is a way to avoid changing of mtime on 
checkout.


P.S. Old version of git FAQ explains taken mtime approach in the same 
way. Build tools relies of modification time comparison:

https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Git_FAQ.html#Why_isn.27t_Git_preserving_modification_time_on_files.3F
(New one is rather brief https://git-scm.com/docs/gitfaq)

Re: /etc/fstab question (problem)?

[David Christensen]

On 4/21/23 08:12, Max Nikulin wrote:

On 20/04/2023 04:03, David Christensen wrote:
* What if root attempts to remove everything under /etc, in 
anticipation of mounting a file system at /etc, when one or more 
programs have one or more open temporary files?


David, you were wrote /etc instead of /tmp in several messages, 



I apologize for the errors.  :-(


I will strive to do more proofreading before posting.


I used initramfs and initrd as synonyms because of file names 
/boot/initrd* and update-initramfs command. Even though /tmp entry 
should not be necessary during early init, I believe, it is safer to run 
"update-initrams -u" just to avoid surprise due to changes in fstab 
several days or weeks later when kernel update will arrive. It would be 
much harder to associate boot failure with fstab restored from backup 
instead of "broken" kernel package.



I am unaware of any single document that would allow us to definitively 
answer the question "what does initrd.img depend upon?".  If anyone 
knows of such, please provide a citation.



I find it strange that we run a tool named "update-initramfs" to update 
a file named "initrd.img-*".  Should not the tool be named "update-initrd"?



I would like to imagine that running update-initramfs(8) is always safe, 
but I seem to be running into a lot of WTF's on Linux and/or Debian again.



I am glad to read that the issue is solved, I see no problem with using 
of live image (it is wise to always have it available).


I think, in this case live image (unlike reboot) was not strictly 
necessary and may reduce down time if it is critical. I think, the 
following is safe enough (not verified, may contain typos or even errors):

- backup /etc/fstab and current initrd
- have a look into grub.cfg and grub manual to be able to boot using 
backup file

- restore /etc/fstab from backup
- Do not run "systemctl daemon-reload", since till shutdown systemd 
should work accordingly to content of old fstab version

- update-initramfs -u
- reboot. It is required after adding /tmp to fstab to make new fstab 
active and after update-initramfs to verify that new fstab does cause 
boot issue. Single reboot should be enough, however another one before 
update-initramfs is possible.

- mount --bind / /mnt
- remove files from /mnt/tmp/ remained from the previous boot. Otherwise 
some large file hidden by mounted /tmp may reduce free space available 
on the / partition

- umount /mnt
- remove initrd backup



As for the Linux initial ramdisk, and ignoring system configuration 
settings in memory:


* The Linux initial ramdisk is a cache used by the boot process.  If 
system configuration settings in a file on primary storage are created/ 
updated/ deleted, if initrd.img depends upon those settings, and if the 
initrd.img is not updated, then the system configuration settings exist 
in two places and those settings are out-of-sync [1,2].  When the system 
is rebooted, the resulting system configuration will be a mixture of 
settings from primary storage files and from initrd.img.


* AIUI the BSD's do not have an initial ramdisk.  If system 
configuration settings in a file on primary storage are created/ 
updated/ deleted, then the system configuration settings exist in only 
one place.  When the system is rebooted, the resulting system 
configuration will be unambiguous.



As for systemd:

* AIUI systemd is a system management database comprised of text and 
binary files.  systemd may hook into initrd.img.  I assume systemd has a 
non-trivial schema with referential integrity requirements.  The text 
files must have a syntax and the binary files must have a file 
structure.  There must be an API to perform operations on all or part of 
the database.  My interactions with systemd have been limited to running 
systemd CLI programs.  If and when the systemd database and/or 
initrd.img components are damaged and/or out-of-sync such that boot 
fails, I have no idea how to fix that.


* AIUI FreeBSD is configured via text files.  I can edit them, check 
them into a version control system, run them through shell pipelines, 
etc..  If and when the system configuration is damaged such that boot 
fails, I know how to boot live media, mount filesystems, and work on 
those files.



David

[1] https://en.wikipedia.org/wiki/Don't_repeat_yourself

[2] https://www.martinfowler.com/bliki/TwoHardThings.html

Re: MariaDB Server is not installing on Debian 12

[The Wanderer]

On 2023-04-21 at 14:11, Cosmin Humeniuc wrote:

> I have the same problem of not being able to install mariadb-server 
> 1:10.11.2-1. The error is the same - a failed attempt to stop 
> mariadb.service or mysql.service.
> 
> In my case, there is no service running for either of them, so I have 
> nothing to stop. I also checked, and there's no mariadb.preinst file in 
> /var/lib/dpkg/info.
> 
> However, I started from these lines in the output:
>  > Errors were encountered while processing:
>  >  /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb
> 
> and I used dpkg-deb to look in that package file. DEBIAN/preinst had a 
> `stop_server()` function that was trying to stop existing servers based 
> on the result of:
>  > pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
> 
> (at line 31). I executed that in a shell and I did get a result - only 
> it wasn't for a running server, but for a standalone process:
>  > pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
>  > 1939
> 
>  > ps aux | grep 1939
>  > cosmin  1939  0.0  1.2 2439604 204892 ?  Sl   19:22   0:02 
> /usr/sbin/mysqld 
> --defaults-file=/home/cosmin/.local/share/akonadi/mysql.conf 
> --datadir=/home/cosmin/.local/share/akonadi/db_data/ 
> --socket=/run/user/1000/akonadi/mysql.socket 
> --pid-file=/run/user/1000/akonadi/mysql.pid

How is that not a server? /usr/sbin/mysqld is the server binary; that
looks like an instance of the server, run by (what I'm presuming is) an
ordinary user rather than by e.g. the 'mysql' account that is used to
run the 'system-wide' instance(s?) of that server.

I could just be blind or ignorant, but I can't see any reason offhand
why that process wouldn't be expected to need to be stopped in just the
same way as those running under other user IDs.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: MariaDB Server is not installing on Debian 12

[Cosmin Humeniuc]

I have the same problem of not being able to install mariadb-server 
1:10.11.2-1. The error is the same - a failed attempt to stop 
mariadb.service or mysql.service.


In my case, there is no service running for either of them, so I have 
nothing to stop. I also checked, and there's no mariadb.preinst file in 
/var/lib/dpkg/info.


However, I started from these lines in the output:
> Errors were encountered while processing:
>  /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb

and I used dpkg-deb to look in that package file. DEBIAN/preinst had a 
`stop_server()` function that was trying to stop existing servers based 
on the result of:

> pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"

(at line 31). I executed that in a shell and I did get a result - only 
it wasn't for a running server, but for a standalone process:

> pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
> 1939

> ps aux | grep 1939
> cosmin  1939  0.0  1.2 2439604 204892 ?  Sl   19:22   0:02 
/usr/sbin/mysqld 
--defaults-file=/home/cosmin/.local/share/akonadi/mysql.conf 
--datadir=/home/cosmin/.local/share/akonadi/db_data/ 
--socket=/run/user/1000/akonadi/mysql.socket 
--pid-file=/run/user/1000/akonadi/mysql.pid


My guess is that the check from `preinst` could be improved to handle 
cases like this. Does it count like a bug? Should I file a report?


--
Cosmin

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

Jeremy Ardley wrote:
...
> I have not used these, but there seem to be some work-arounds for 
> storing metadata in/with git
>
> lfs has the ability to script xattr handling
>
> https://git-lfs.github.com/

  i'll look at that one and see if it brings things to mind
that i've already messed with it before.  sometimes i go 
looking and do try things, but my recent few months have
been busy with other projects.

  um, no, i don't want large files being shipped off or
linked to some other service.  that's not what my gripe
is about at all.


> These applications work directly with metadata and can be scripted into 
> the git process:
>
> Metastore: https://github.com/przemoc/metastore
>
> Git-meta: https://github.com/chasinglogic/git-meta

  i've dabbled with that one but not gone further.


> None of these will handle NTFS Alternate Data Streams, so archive 
> operations between windows and linux are guaranteed to lose data and 
> metadata.

  i don't do stuff with Windows or NTFS any longer so that
doesn't matter to me, i just want file attributes copied
and restored properly.


  songbird

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 21/04/2023 11:26, David Wright wrote:

On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:


Opt-out variant for ESP sounds reasonable for me. However I am unsure
if it is possible to complete installation with no ESP at all.


If you mean: to install Grub but not write to the ESP,


No, I did not go so far. I wrote about partitioning screen. It is 
possible to select ESP partition and mark it "Do not use". My 
expectation is that it should prevent installing grub to ESP. However it 
is easy to forget about the "K" flag (partition will be used by installer).


My point is that if a partition is marked for usage as ESP then it is 
not "without explicit notification and permission".



┌─┤ [!] Install the GRUB boot loader ├──┐


Is it shown in the case of default debconf priority or it is necessary 
to switch to "low"?


Frankly speaking, from this text it is unclear for me if the question is 
related to putting files to EFI/debian or to creation of new Boot 
NVRAM variable with possible modification of BootOrder.



│ The following other operating systems have been detected on this  │
│ computer: Debian GNU/Linux 11 (bullseye)  │
│   │
│ If all of your operating systems are listed above, then it should be  │
│ safe to install the boot loader to your primary drive (UEFI   │
│ partition/boot record).


Side note. I do not think it is safe to install *Debian* boot loader 
when another *Debian* is detected. It will overwrite EFI/debian/grub.cfg 
and so will make earlier installed debian not bootable. Either I missed 
something or it is fragile to manage grub configuration shared by 2 
independent debian (or other linux distributions) systems.



Bullseye had a misfeature where it would, even on a BIOS machine,
solicit installing to the fallback location.


Do you mean installing grub to EFI/BOOT (layout for removable storage)? 
I have an almost 10 years old HP laptop with buggy firmware. The easiest 
way to make linux bootable is to put grub into EFI/BOOT (and remove 
fbx64.efi fallback binary that attempts to adjust Boot and ignored 
BootOrder on each boot). It is possible to select any boot entry from F9 
menu, but by default it boots from EFI/BOOT/bootx64.efi.



2. On a laptop having ESP partitions on 2 disks, both ones are marked
for usage as ESP. I am unsure if it causes installation error later or
grub is installed on both ones (taking into account single /boot/efi
mount point).


I would assume not, as people complain about this as a single point of
failure in UEFI booting. I haven't tried repeating "Install the GRUB
boot loader" from the Main Menu, but I don't see why it shouldn't
work. But I don't think that that would get you two entries in NVRAM
without playing some tricks.


On that HP laptop I manually installed grub to second ESP. The result is 
2 indistinguishable entries in F9 boot menu. The text is taken from 
shim/BOOTX64.CSV, no other hints displayed.

Re: /etc/fstab question (problem)?

[Max Nikulin]

On 20/04/2023 04:03, David Christensen wrote:
* What if root attempts to remove everything under /etc, in anticipation 
of mounting a file system at /etc, when one or more programs have one or 
more open temporary files?


David, you were wrote /etc instead of /tmp in several messages, so at 
certain moment I thought that original issue was due to attempt to 
really mount another partition to /etc (e.g. for easier backups). Later 
an entry for /tmp was added to fstab on mounted partition, perhaps new 
version of fstab even propagated to initramfs. However after reboot 
there was no an entry for /etc in the /etc/fstab file residing on the 
root partition, so init had no change to mount /etc with another fstab 
(with the entry for /etc). It is literally bootstrap problem. 
Fortunately Default User posted complete fstab, so it was possible to 
rule out such hypothesis.


I used initramfs and initrd as synonyms because of file names 
/boot/initrd* and update-initramfs command. Even though /tmp entry 
should not be necessary during early init, I believe, it is safer to run 
"update-initrams -u" just to avoid surprise due to changes in fstab 
several days or weeks later when kernel update will arrive. It would be 
much harder to associate boot failure with fstab restored from backup 
instead of "broken" kernel package.


I am glad to read that the issue is solved, I see no problem with using 
of live image (it is wise to always have it available).


I think, in this case live image (unlike reboot) was not strictly 
necessary and may reduce down time if it is critical. I think, the 
following is safe enough (not verified, may contain typos or even errors):

- backup /etc/fstab and current initrd
- have a look into grub.cfg and grub manual to be able to boot using 
backup file

- restore /etc/fstab from backup
- Do not run "systemctl daemon-reload", since till shutdown systemd 
should work accordingly to content of old fstab version

- update-initramfs -u
- reboot. It is required after adding /tmp to fstab to make new fstab 
active and after update-initramfs to verify that new fstab does cause 
boot issue. Single reboot should be enough, however another one before 
update-initramfs is possible.

- mount --bind / /mnt
- remove files from /mnt/tmp/ remained from the previous boot. Otherwise 
some large file hidden by mounted /tmp may reduce free space available 
on the / partition

- umount /mnt
- remove initrd backup

Re: Map URL to a container...

[Dan Ritter]

nimrod wrote: 
> Hi,
> 
> I'm running a web server inside an LXD container which is only
> accessible from the host. I mapped the container's 80 port to the 82
> host's port, so I can access the container's web server as
> http://host:82. The host itself runs Apache on the usual 80 port. What
> I whis to get is something like this:
> 
> http://host/path1 --> http://localip/path1
> http://host/path2 --> http://localip/path2
> 
> and so on and so forth. How can I do it?


You want Apache to act as a reverse proxy for the localip:port.

https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html

Note that your localip is the "backend" server. Use the Simple
Reverse Proxy config with ProxyPass and ProxyPassReverse.

-dsr-

Map URL to a container...

[nimrod]

Hi,

I'm running a web server inside an LXD container which is only
accessible from the host. I mapped the container's 80 port to the 82
host's port, so I can access the container's web server as
http://host:82. The host itself runs Apache on the usual 80 port. What
I whis to get is something like this:

http://host/path1 --> http://localip/path1
http://host/path2 --> http://localip/path2

and so on and so forth. How can I do it?

Best regards.

Re: /etc/fstab question (problem)?

[Greg Wooledge]

On Fri, Apr 21, 2023 at 04:59:36AM -0400, rhkra...@gmail.com wrote:
> On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> > sudo cp -r   from the live usb.
> 
> Recently I've been trying to get in the habit of using cp -aru because those 
> options do what I usually want:
> 
>* -a preserves dates (and ownership and permissions), and doesn't follow 
> (copy from) symbolic links
>* -r recurses through subdirectories
>* -u copies only if the destination file is older than the file to be 
> copied

In GNU cp(1):

   -a, --archive
  same as -dR --preserve=all

   -d same as --no-dereference --preserve=links

   -R, -r, --recursive
  copy directories recursively

So, your -r is redundant.  It's included in the -a.

Re: Second monitor doesn't quite work

[Vincent Lefevre]

On 2023-04-21 13:01:29 +0200, Vincent Lefevre wrote:
> I've found the details of the issue I got when I had no xorg.conf
> file (that was in May 2020, thus 3 years ago) and 3 connected outputs
> (laptop screen + 2 external monitors). At boot, the driver randomly
> chose 2 of them. But when I logged out and the X server was restarted
> by lightdm, I got the following error:
[...]

And at that time, I did some search to find the cause, and I had found
some document or web page where it was said that the Nvidia driver
(at least the one for Linux) supported up to 2 enabled outputs.
Unfortunately, it appears that I haven't kept any reference, and
now, I can't find one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Second monitor doesn't quite work

[Vincent Lefevre]

On 2023-04-21 10:01:53 +0100, Eric S Fraga wrote:
> On Thursday, 20 Apr 2023 at 14:34, Vincent Lefevre wrote:
> > In my case, an empty xorg.conf doesn't work with my 3-monitor setup.
> > The issue is that the Nvidia driver (contrary to nouveau?) doesn't
> > work with 3 monitors, so one of them cannot be used, but when the
> > X server is restarted (e.g. when I log out), the Nvidia driver is
> > confused about which monitor to use.
> 
> Interesting.  I've had a look at my Xorg.log file and I'm using the
> nvidia driver and it is finding all three monitors.  My graphics card is
> 
> :65:00.0 VGA compatible controller: NVIDIA Corporation GP107GL [Quadro 
> P1000] (rev a1)

I've found the details of the issue I got when I had no xorg.conf
file (that was in May 2020, thus 3 years ago) and 3 connected outputs
(laptop screen + 2 external monitors). At boot, the driver randomly
chose 2 of them. But when I logged out and the X server was restarted
by lightdm, I got the following error:

[79.224] (==) NVIDIA(0):
[79.224] (==) NVIDIA(0): No modes were requested; the default mode 
"nvidia-auto-select"
[79.224] (==) NVIDIA(0): will be used as the requested mode.
[79.224] (==) NVIDIA(0):
[79.225] (WW) NVIDIA(0): No valid modes for
[79.225] (WW) NVIDIA(0): 
"DFP-3:nvidia-auto-select,DFP-4:nvidia-auto-select,DFP-5:nvidia-auto-select";
[79.225] (WW) NVIDIA(0): removing.
[79.225] (WW) NVIDIA(0):
[79.225] (WW) NVIDIA(0): Unable to validate any modes; falling back to the 
default mode
[79.225] (WW) NVIDIA(0): "nvidia-auto-select".
[79.225] (WW) NVIDIA(0):
[79.226] (WW) NVIDIA(0): No valid modes for
[79.226] (WW) NVIDIA(0): 
"DFP-3:nvidia-auto-select,DFP-4:nvidia-auto-select,DFP-5:nvidia-auto-select";
[79.226] (WW) NVIDIA(0): removing.
[79.226] (EE) NVIDIA(0): Unable to use default mode "nvidia-auto-select".
[79.226] (EE) NVIDIA(0): Failing initialization of X screen 0
[79.809] (II) UnloadModule: "nvidia"
[79.809] (II) UnloadSubModule: "wfb"
[79.809] (II) UnloadSubModule: "fb"
[79.809] (EE) Screen(s) found, but none have a usable configuration.
[79.809] (EE)
Fatal server error:
[79.809] (EE) no screens found(EE)

This is with GK208GLM [Quadro K610M], which supports up to 4 outputs.
So this is a driver issue (this was version 390.132-4).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Second monitor doesn't quite work

[Eric S Fraga]

On Thursday, 20 Apr 2023 at 14:34, Vincent Lefevre wrote:
> In my case, an empty xorg.conf doesn't work with my 3-monitor setup.
> The issue is that the Nvidia driver (contrary to nouveau?) doesn't
> work with 3 monitors, so one of them cannot be used, but when the
> X server is restarted (e.g. when I log out), the Nvidia driver is
> confused about which monitor to use.

Interesting.  I've had a look at my Xorg.log file and I'm using the
nvidia driver and it is finding all three monitors.  My graphics card is

:65:00.0 VGA compatible controller: NVIDIA Corporation GP107GL [Quadro 
P1000] (rev a1)

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-04-18) on Debian 11.5

Re: /etc/fstab question (problem)?

[rhkramer]

On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> sudo cp -r   from the live usb.

Recently I've been trying to get in the habit of using cp -aru because those 
options do what I usually want:

   * -a preserves dates (and ownership and permissions), and doesn't follow 
(copy from) symbolic links
   * -r recurses through subdirectories
   * -u copies only if the destination file is older than the file to be copied

-- 
rhk 

(sig revised 20230312 -- modified first paragraph, some other irrelevant 
wordsmithing)

| No entity has permission to use this email to train an AI. 

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking. (That speaker might have 
been "trained" to do this by being interrupted often if he pauses.)  (Remember 
Cicero who did not have enough time to write a short missive.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'

AW: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Schwibinger Michael]

Good morning
Thank You
Is the problem
I did make the wrong ,,blank,, ?

I am sorry.


Regards Sophie





Von: The Wanderer
Gesendet: Freitag, 14. April 2023 23:06
Bis: debian-user@lists.debian.org
Betreff: Re: EPSON ET M 1120 new printer: If You can read this, you are using 
the wrong driver

On 2023-04-14 at 18:52, Brian wrote:

> On Fri 14 Apr 2023 at 18:22:09 -0400, The Wanderer wrote:
>
>> On 2023-04-14 at 18:10, Brian wrote:

>> > You could consider:
>> >
>> >   * Stating the Debain OS being used.
>> >   * Giving the printer make and model.
>>
>> The make *was* stated: Epson.
>>
>> The model may also have been stated, albeig only in the Subject line: ET
>> M1120. From a bit of Googling, the "ET" appears to stand for "EcoTank".
>
> The EPSON ET M 1120 doesn't exist. Do we have to guess its correct name as 
> well
> as any other relevant information?

When I searched for

Epson ET M 1120

I got a suggestion that I may have meant "M1120" instead of the last two
search terms, and hits for the "Epson EcoTank ET M1120" and/or "Epson
EcoTank M1120", which look to be different names for the same model and
to be a fairly clear match.

While, yes, specifying the exact name clearly would be preferable, this
is far from unreasonably difficult to figure out.

>> >   * Specifying the connection method. USB. Network.
>> >   * Giving the exact error message and where it came from.
>>
>> Also:
>>
>> * Starting a new thread to discuss the matter, rather than replying
>> to an existing message deep in an existing thread, deleting the
>> body, and changing the Subject line before sending.
>>
>> (This question, and its replies, are appearing as responses to a
>> mail from Michael Stone in the 'update-initramfs' thread.)
>
> I haven't a clue what you are going on about here. Shift-L in mutt
> was used at this end.

Your replies to the OP have been fine, AFAIK. The OP's message was
itself a reply, as can be seen by looking at its headers (In-Reply-To:
and References:), but was otherwise presented as if it had been the
start of a new thread; that is not fine, because it hides the "new
thread" inside of the existing one, at least for anyone using a threaded
view of the list of messages.

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

Re: Bookworm: dash shell globs don't recognise [^...] to negate a character class

[Max Nikulin]

On 20/04/2023 03:18, davidson wrote:

On Wed, 19 Apr 2023 Max Nikulin wrote:

On 18/04/2023 21:19, Vincent Lefevre wrote:

BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.


It would be great. Unfortunately disabling histexpand option in bash 
blocks the M-^ shortcut as well.


shopt -s histverify

allows at least to confirm that expansion result is expected.


There is also the 'p' (print) modifier, that prints the


I corrected the line above basing on your another message.


expansion but does not execute it. Used like so:

  $ !.:p # See what the history expansion for 'dot' is
  . .bash_functions/manterm

This places the expansion in history as last command, so up-arrow +
return will now execute it.


It is nice to have such feature. Likely you actively use history 
expansion, while I prefer interactive approach: search (C-r), edit, 
including yank-last-arg (M-.), perhaps operate-and-get-next (C-o). I 
find it safer even if it is not so fast.


Unfortunately :p modifier does not prevent unexpected history expansion, 
e.g. when a file name contains "!". That is why I would prefer to 
suppress history expansion for every typed command, but still have 
possibility to perform expansion on request (M-^ or similar shortcut), 
perhaps limiting it to a single "!" before cursor.


histverify is a means to cancel command if unsolicited expansion or 
unexpected result noticed.