On 25/01/2025 14:17, Thomas Anderson wrote:
$ nmcli connection show
IP4.ADDRESS[1]: 192.168.1.6/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 192.168.1.0/24, nh =
0.0.0.0, mt = 100
IP4.ROUTE[2]:
Hi Thomas,
On Sat, Jan 25, 2025 at 08:17:44AM +0100, Thomas Anderson wrote:
> $ nmcli connection show "Wired connection 1"
>
> nnection.id: Wired connection 1
> ipv4.method: manual
> ipv4.dns: 192.168.1.8
> ipv4.add
$ nmcli connection show
NAME UUID TYPE DEVICE
Wired connection 1 fc7feb2f-f189-44c3-b06c-88d053fd087f ethernet enp27s0
$ nmcli connection show "Wired connection 1"
nnection.id: Wired connection 1
connection.uuid: fc7feb2f-f189-44c3-b06c-88d053fd087
Hi Thomas,
On Fri, Jan 24, 2025 at 06:48:08PM +0100, Thomas Anderson wrote:
> ip a ->
> 2: enp27s0: mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
> link/ether 30:9c:23:b7:48:8c brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.6/24 brd 192.168.1.255 scope global noprefixroute enp27s0
I see. Thanks Greg. Let's see if this works
ip a ->
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
On Fri, Jan 24, 2025 at 17:11:06 +0100, Thomas Anderson wrote:
> Here is updated version with
CR in this context means carriage returns. Which is actually not the
correct term -- they meant LF (line feed) or newlines.
But what they *really* meant was for you to send the message as plain
text, n
On Fri, 24 Jan 2025 16:14:05 +0100
Thomas Anderson wrote:
> Thanks for thorough reply.
>
> 1. I am talking about basic network connection. I have an ip, so I
> can ping local machines, including the gateway router itself.
>
> 'ip a' shows the following
>
> 1: lo: mtu 65536 qdisc noqueue state
Here is updated version with
Thanks for thorough reply.
1. I am talking about basic network connection. I have an ip, so I can
ping local machines, including the gateway router itself.
'ip a'
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00
On 2025-01-24, Thomas Anderson wrote:
> 'ip a' shows the following
> 'cat /etc/network/interfaces.d/*' shows
Could you give us the result with CR. It's unreadable without, especially
for commented lines.
Perhaps give also
ip r
Thanks for thorough reply.
1. I am talking about basic network connection. I have an ip, so I can
ping local machines, including the gateway router itself.
'ip a' shows the following
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:0
Hi Thomas,
On Friday, 24 January 2025 08:35:44 GMT-4 Thomas Anderson wrote:
> Hello,
>
> I am using Debian 11, and no matter what I do, I repeated on each
> reboot, I will boot into a system with no gateway set (or rather, the
> "default route is 0.0.0.0," which naturally gives this device no
> in
Hello,
I am using Debian 11, and no matter what I do, I repeated on each
reboot, I will boot into a system with no gateway set (or rather, the
"default route is 0.0.0.0," which naturally gives this device no
internet connectivity.
I am using the NetworkManager, and have a static IP set.
If
Hi,
Recently when running "apt update" in my VM (under virt-manager) running
Debian testing I see this error in the middle:
,
| Error: No line left in add_len data to skip (1)
| Error: Parsing patchfile
/var/lib/apt/lists/partial/deb.debian.org_debian_dists_trixie_main_Contents-source.lz4.ed
On Sun, Dec 08, 2024 at 19:44:49 +0100, Harald Dunkel wrote:
> version number for tzdata in bullseye is 2024b-0+deb11u1, but
> for bookworm it is still 2024a-0+deb12u1. This seems weird.
> Shouldn't the bookworm version number be "newer" than the bullseye
> version?
Hi folks,
version number for tzdata in bullseye is 2024b-0+deb11u1, but
for bookworm it is still 2024a-0+deb12u1. This seems weird.
Shouldn't the bookworm version number be "newer" than the bullseye
version?
Regards
Harri
On Sat, Sep 28, 2024 at 03:46:34PM -0500, Mike Waters wrote:
> Testing with Gmail to see if I absolutely need to install mutt.
Don't do those things
- use gmail. Google ain't your friend. Nor mine.
- hijack a thread (if you are too lazy to enter the mailing list,
at least delete the relevant he
Hello,
sometimes some cooperative sites had similar problems e.g MS's O365 or
Oracle's support site. In these cases removing stored cookies and
website data helped.
In addition cache can be deactivated in FF Developer Console
(Ctrl-Shift-k) in the tab "Network(ing)". Here you have a checkbox
On Thu, May 23, 2024 at 12:09:42PM +0200, local10 wrote:
> May 23, 2024, 02:11 by 2695bd53d...@ewoof.net:
>
> > Works fine for me too, on the same firefox-esr package version.
> >
> > If clearing the browser cache doesn't help, try with a brand new fresh
> > profile. `firefox --no-remote --new-ins
May 23, 2024, 02:11 by 2695bd53d...@ewoof.net:
> Works fine for me too, on the same firefox-esr package version.
>
> If clearing the browser cache doesn't help, try with a brand new fresh
> profile. `firefox --no-remote --new-instance --ProfileManager` should
> be a good start. If it works in a br
On 22 May 2024 15:17 -0600, from charlescur...@charlescurley.com (Charles
Curley):
>> about a week ago when I started
>> to get a blank empty white page when trying to access the Tutanota
>> login page: https://mail.tutanota.com/login
>
> I get what looks like a proper log-in page on both firefox
On Wed, 22 May 2024 23:02:17 +0200 (CEST)
local10 wrote:
> Have been using Debian + Firefox with Tutanota email for a number of
> years and everything was fine until about a week ago when I started
> to get a blank empty white page when trying to access the Tutanota
> login page: https://mail.tut
Hi,
Have been using Debian + Firefox with Tutanota email for a number of years and
everything was fine until about a week ago when I started to get a blank empty
white page when trying to access the Tutanota login page:
https://mail.tutanota.com/login
Tried https://mail.tutanota.com/login in C
Am 22.11.2023 um 12:00:52 Uhr schrieb Nicolas George:
> Thanks for clarifying. But AFAIK, with proxy ARP, the network mask
> covers all the networks covered by the proxy. That is not the case
> here.
Does your Router have a default route?
The it covers 0.0.0.0/0.
Am 22.11.2023 um 11:58:55 Uhr schrieb Nicolas George:
> I do not see what the router has to do with anything. Can you
> elaborate what you mean?
Proxy-ARP offers the possibility to answer ARP requests of addresses
outside the own subnet sitting on another ethernet link.
In normal cases that is no
Marco Moock (12023-11-22):
> Sorry, not gracious-arp, proxy-arp can be responsible for that.
Thanks for clarifying. But AFAIK, with proxy ARP, the network mask
covers all the networks covered by the proxy. That is not the case here.
Regards,
--
Nicolas George
Marco Moock (12023-11-22):
> Are those networks on the same ethernet link?
No, they are on a different VLAN.
> Are some systems with wrong subnet masks on the link and the router has
> gratious ARP enabled?
I do not see what the router has to do with anything. Can you elaborate
what you mean?
O
Am 22.11.2023 um 11:51:36 Uhr schrieb Marco Moock:
> Are some systems with wrong subnet masks on the link and the router
> has gratious ARP enabled?
Sorry, not gracious-arp, proxy-arp can be responsible for that.
Am 22.11.2023 um 11:29:47 Uhr schrieb Nicolas George:
> As you can see, the server is on the …96.0/22 subnet, i.e. …96-…99,
> but it sees MAC addresses on the 100 and 103 networks.
Are those networks on the same ethernet link?
Are some systems with wrong subnet masks on the link and the router ha
Hi.
Since last we have four MAC addresses in the ARP table of a server that
should not be there:
$ ip route
default via XXX.XXX.98.254 dev eth0 onlink
XXX.XXX.96.0/22 dev eth0 proto kernel scope link src XXX.XXX.98.94
But:
$ ip neigh | grep -v 'XXX.XXX.9[6789]'
XXX.XXX.103.161 dev eth0 lla
On 8/10/23 10:44 PM, Maureen L Thomas wrote:
Sorry, it was late when I posted this. I am using Bookworm and
checked the log not figuring on finding anything and found this. My
system has been upgrade to the last fixes for Bookworm. I am using a
Lanova all in one machine. 2TB hard drive
Sorry, it was late when I posted this. I am using Bookworm and checked
the log not figuring on finding anything and found this. My system has
been upgrade to the last fixes for Bookworm. I am using a Lanova all in
one machine. 2TB hard drive with 8 for ram.
Moe
On 8/8/23 7:57 AM, Henning
On Tue, Aug 08, 2023 at 03:12:59PM -0400, Maureen L Thomas wrote:
>
Thanks for not top posting. I fixed it for you...
> On 8/8/23 7:57 AM, Henning Follmann wrote:
> > On Tue, Aug 08, 2023 at 12:01:08AM -0400, Maureen L Thomas wrote:
> > > 3:24:29 PM systemd: Failed to start tracker-extract-3.ser
Sorry, it was late when I posted this. I am using Bookworm and checked
the log not figuring on finding anything and found this. My system has
been upgrade to the last fixes. I am using a Lanova all in one machine.
Moe
On 8/8/23 7:57 AM, Henning Follmann wrote:
On Tue, Aug 08, 2023 at 12:01:
On Tue, Aug 08, 2023 at 12:01:08AM -0400, Maureen L Thomas wrote:
> 3:24:29 PM systemd: Failed to start tracker-extract-3.service - Tracker
> metadata extractor.
> 3:24:29 PM systemd: Failed to start tracker-extract-3.service - Tracker
> metadata extractor.
> 3:23:59 PM systemd: Failed to start
3:24:29 PM systemd: Failed to start tracker-extract-3.service - Tracker
metadata extractor.
3:24:29 PM systemd: Failed to start tracker-extract-3.service - Tracker
metadata extractor.
3:23:59 PM systemd: Failed to start tracker-extract-3.service - Tracker
metadata extractor.
3:23:29 PM syste
On 5/28/23 03:09, Christian wrote:
Ursprüngliche Nachricht
Von: David Christensen
An: debian-user@lists.debian.org
Betreff: Re: Weird behaviour on System under high load
Datum: Sat, 27 May 2023 16:30:05 -0700
On 5/27/23 15:28, Christian wrote:
New day, new tests. Got a
> Ursprüngliche Nachricht
> Von: David Christensen
> An: debian-user@lists.debian.org
> Betreff: Re: Weird behaviour on System under high load
> Datum: Sat, 27 May 2023 16:30:05 -0700
>
> On 5/27/23 15:28, Christian wrote:
>
> > New day, new tes
On 5/27/23 15:28, Christian wrote:
New day, new tests. Got a crash again, however with the message "AHCI
controller unavailable".
Figured that is the SATA drives not being plugged in the right order.
Corrected that and a 3:30h stress test went so far without any issues
besides this old bug
https
> Ursprüngliche Nachricht
> Von: David Christensen
> An: debian-user@lists.debian.org
> Betreff: Re: Weird behaviour on System under high load
> Datum: Fri, 26 May 2023 18:22:17 -0700
>
> On 5/26/23 16:08, Christian wrote:
>
> > Good and bad
On 5/26/23 16:08, Christian wrote:
Good and bad things:
I started to test different setups (always with full 12 core stress
test). Boot from USB liveCD (only stress and s-tui installed):
- All disks disconnected, other than M2. Standard BIOS
- All disks disconnected, other than M2. Proper Memor
> Ursprüngliche Nachricht
> Von: David Christensen
> An: debian-user@lists.debian.org
> Betreff: Re: Weird behaviour on System under high load
> Datum: Sun, 21 May 2023 15:04:44 -0700
>
>
> > > > > What stresstest are you using?
>
>
On 5/21/23 14:46, Christian wrote:
David Christensen Sun, 21 May 2023 14:22:22 -0700
On 5/21/23 06:31, Christian wrote:
David Christensen Sun, 21 May 2023 03:11:43 -0700
David Christensen Sat, 20 May 2023 18:00:48 -0700
Heat sinks, heat pipes, water blocks, radiators, fans, ducts, etc..
I
> Ursprüngliche Nachricht
> Von: David Christensen
> An: debian-user@lists.debian.org
> Betreff: Re: Weird behaviour on System under high load
> Datum: Sun, 21 May 2023 14:22:22 -0700
>
> On 5/21/23 06:31, Christian wrote:
> > David Christensen Sun,
ultiple stages that produce +12 VDC, +5
VDC, +5 VDC standby, +3.3 VDC, and -12 VDC ("rails"). It is common for
one or more rails to fail and the others to continue working. Computers
exhibit "weird behaviour" when this happens.
Just spend the US$20.
Have you tested t
On 5/21/23 06:26, songbird wrote:
David Christensen wrote:
...
Measuring actual power supply output and system usage would involve
building or buying suitable test equipment. The cost would be non-trivial.
...
it depends upon how accurate you want to be and
how much power.
for my syst
David Christensen wrote:
...
> Measuring actual power supply output and system usage would involve
> building or buying suitable test equipment. The cost would be non-trivial.
...
it depends upon how accurate you want to be and
how much power.
for my system it was a simple matter of buying
> Ursprüngliche Nachricht
> Von: David Christensen
> An: debian-user@lists.debian.org
> Betreff: Re: Weird behaviour on System under high load
> Datum: Sun, 21 May 2023 03:11:43 -0700
>
> On 5/21/23 01:14, Christian wrote:
>
> > >
On 5/21/23 01:14, Christian wrote:
Ursprüngliche Nachricht
Von: David Christensen
An: debian-user@lists.debian.org
Betreff: Re: Weird behaviour on System under high load
Datum: Sat, 20 May 2023 18:00:48 -0700
On 5/20/23 14:46, Christian wrote:
Hi there,
I am having trouble
where
unmounted. So would guess this would be a test to see if it is about
power?
Ursprüngliche Nachricht
Von: David Christensen
An: debian-user@lists.debian.org
Betreff: Re: Weird behaviour on System under high load
Datum: Sat, 20 May 2023 18:00:48 -0700
On 5/20/23 14:46, Chri
On 5/20/23 14:46, Christian wrote:
Hi there,
I am having trouble with a new build system. It works normal and stable
until I put extreme stress on it, e.g. using all 12 cores with stress
tool.
System will suddenly loose network connection and become unresponsive.
Only a reset works. I am not su
Hi there,
I am having trouble with a new build system. It works normal and stable
until I put extreme stress on it, e.g. using all 12 cores with stress
tool.
System will suddenly loose network connection and become unresponsive.
Only a reset works. I am not sure what is going on, but it is
reprod
debian-u...@howorth.org.uk writes:
>> I don't understand, there is no ImageMagick ML/group
>> registered on Gmane, and just some <10 people on
>> #imagemagick on Libera?
>>
>> People don't care about this software which is the CLI
>> powerhouse for image editing?
>
> I occasionally us
Emanuel Berg wrote:
> I don't understand, there is no ImageMagick ML/group
> registered on Gmane, and just some <10 people on #imagemagick
> on Libera?
>
> People don't care about this software which is the CLI
> powerhouse for image editing?
I occasionally use ImageMagick but never
I don't understand, there is no ImageMagick ML/group
registered on Gmane, and just some <10 people on #imagemagick
on Libera?
People don't care about this software which is the CLI
powerhouse for image editing?
--
underground experts united
https://dataswamp.org/~incal
I just wrote some zsh/imagemagick to resize files and then pad
them to a specific image file resolution, however the color of
the rectangle, if I set that to "black" (or #00) the colors
get screwed up.
If I set it to #01 tho it works, have no idea why.
Here is the source, the line that bu
On Thu, Nov 10, 2022 at 05:54:00AM +0100, hw wrote:
ls -la
insgesamt 5
drwxr-xr-x 3 namefoo namefoo 3 16. Aug 22:36 .
drwxr-xr-x 24 root root 4096 1. Nov 2017 ..
drwxr-xr-x 2 namefoo namefoo 2 21. Jan 2020 ?
namefoo@host /srv/datadir $ ls -la '?'
ls: Zugriff auf ? nicht möglich:
rated, two-column, hexa‐
decimal bytes, followed by the same sixteen bytes in %_p format
enclosed in '|' characters. Invoking the program as hd implies
this option.
Why on earth the default format of "hexdump" uses that weird 16-bit
little endian nonsense is beyond me.
On Thu, 2022-11-10 at 09:30 -0500, Greg Wooledge wrote:
> On Thu, Nov 10, 2022 at 02:48:28PM +0100, hw wrote:
> > On Thu, 2022-11-10 at 07:03 -0500, Greg Wooledge wrote:
>
> [...]
> > printf '%s\0' * | hexdump
> > 000 00c2 6177 7468
> > 007
>
> I dislike this outp
On Thu, Nov 10, 2022 at 02:48:28PM +0100, hw wrote:
> On Thu, 2022-11-10 at 07:03 -0500, Greg Wooledge wrote:
> good idea:
>
> printf %s * | hexdump
> 000 77c2 6861 0074
> 005
Looks like there might be more than one file here.
> > If you misrepresented the situat
On Thu, 2022-11-10 at 07:03 -0500, Greg Wooledge wrote:
> On Thu, Nov 10, 2022 at 05:54:00AM +0100, hw wrote:
> > ls -la
> > insgesamt 5
> > drwxr-xr-x 3 namefoo namefoo 3 16. Aug 22:36 .
> > drwxr-xr-x 24 root root 4096 1. Nov 2017 ..
> > drwxr-xr-x 2 namefoo namefoo 2 21. Jan 2020
On Fri, 26 Aug 2022, Tim Woodall wrote:
$ cat Makefile.test
...
Many thanks everybody for all of the help understanding this.
Not this exact issue but effectively the same was reported in bug
#944780 and the unbound variable in /etc/bash.bashrc was reported in
#941248
I've now submitted a
On Sun, 28 Aug 2022 at 01:30, Greg Wooledge wrote:
> On Sun, Aug 28, 2022 at 12:46:17AM +1000, David wrote:
> > I think there might be one remaining aspect still mysterious, so there
> > might be yet another factor beyond the FIVE you identified ...
> >
> > The fact that this statement, first sho
On Sun, Aug 28, 2022 at 12:46:17AM +1000, David wrote:
> I think there might be one remaining aspect still mysterious, so there
> might be yet another factor beyond the FIVE you identified ...
>
> The fact that this statement, first shown by Tim, does NOT error:
>
> $ ( bash -uc : ; : )
(insid
On Sun, 28 Aug 2022 at 00:17, Greg Wooledge wrote:
> On Sat, Aug 27, 2022 at 09:52:11AM -0400, Greg Wooledge wrote:
> > I also can't explain this (still inside the ssh localhost session):
> >
> > unicorn:~$ (bash -c 'declare -p PS1')
> > declare -- PS1="\\h:\\w\\\$ "
> > unicorn:~$ (bash -cu 'dec
On Sat, Aug 27, 2022 at 09:52:11AM -0400, Greg Wooledge wrote:
> I also can't explain this (still inside the ssh localhost session):
>
>
> unicorn:~$ (bash -c 'declare -p PS1')
> declare -- PS1="\\h:\\w\\\$ "
> unicorn:~$ (bash -cu 'declare -p PS1')
> /etc/bash.bashrc: line 7: PS1: unbound variab
On Sat, Aug 27, 2022 at 05:12:57PM +1000, David wrote:
> I have modified my ssh environment so that it is not the default.
> But I do see a similar error message, using ssh from stable Debian 11.
>
> [david@kablamm ~]$ ( bash -cu : )
> [david@kablamm ~]$ ssh kablamm
> Linux kablamm 5.10.0-16-amd64
On Sat, Aug 27, 2022 at 12:11:47AM -0500, David Wright wrote:
> On Sat 27 Aug 2022 at 00:23:10 (-0400), gene heskett wrote:
> > On 8/26/22 20:35, David wrote:
> > > On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> > > > I get these results as well, with Debian 11's packaged bash.
> > > Yeah, s
On Sat, 27 Aug 2022 at 16:49, Tim Woodall wrote:
> This just gets weirder and weirder.
>
> It looks like it's related to logging in with ssh:
[..]
> apt-mirror@aptmirror17:~$ ( bash -cu : )
> apt-mirror@aptmirror17:~$
> apt-mirror@aptmirror17:~$ ssh aptmirror17
> Last login: Sat Aug 27 06:23:1
On Sat, Aug 27, 2022 at 07:49:17AM +0100, Tim Woodall wrote:
> On Sat, 27 Aug 2022, to...@tuxteam.de wrote:
>
> > On Sat, Aug 27, 2022 at 11:22:09AM +1000, David wrote:
> > > On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> > >
> > > > Has anyone managed to reproduce the OP's results, either
On Sat, 27 Aug 2022, to...@tuxteam.de wrote:
On Sat, Aug 27, 2022 at 11:22:09AM +1000, David wrote:
On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
Has anyone managed to reproduce the OP's results, either getting
"interactive" from a bash -c call, or seeing *any* evidence that
/etc/bash.b
On Sat, 27 Aug 2022 at 15:07, wrote:
> On Sat, Aug 27, 2022 at 11:22:09AM +1000, David wrote:
> > On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> > > Has anyone managed to reproduce the OP's results, either getting
> > > "interactive" from a bash -c call, or seeing *any* evidence that
> > >
On Sat 27 Aug 2022 at 00:23:10 (-0400), gene heskett wrote:
> On 8/26/22 20:35, David wrote:
> > On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> > > I get these results as well, with Debian 11's packaged bash.
> > Yeah, sorry, I forgot to include, for the record:
> >
> > $ echo $BASH_VERSION
On Sat, Aug 27, 2022 at 11:22:09AM +1000, David wrote:
> On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
>
> > Has anyone managed to reproduce the OP's results, either getting
> > "interactive" from a bash -c call, or seeing *any* evidence that
> > /etc/bash.bashrc or ~/.bashrc is sourced from
On Sat, Aug 27, 2022 at 10:32:06AM +1000, David wrote:
> On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> > On Sat, Aug 27, 2022 at 10:21:08AM +1000, David wrote:
>
> > > Just sharing something that I tried, to shed some more light
> > > on this, in case that's useful ...
> > >
> > > $ foo()
On 8/26/22 20:35, David wrote:
On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
On Sat, Aug 27, 2022 at 10:21:08AM +1000, David wrote:
Just sharing something that I tried, to shed some more light
on this, in case that's useful ...
$ foo() { case "$-" in *i* ) i=interactive ;; * ) i=not-inte
On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> Has anyone managed to reproduce the OP's results, either getting
> "interactive" from a bash -c call, or seeing *any* evidence that
> /etc/bash.bashrc or ~/.bashrc is sourced from a bash -c call?
On Debian 11, when I create a test user, login
On Sat, 27 Aug 2022 at 10:27, Greg Wooledge wrote:
> On Sat, Aug 27, 2022 at 10:21:08AM +1000, David wrote:
> > Just sharing something that I tried, to shed some more light
> > on this, in case that's useful ...
> >
> > $ foo() { case "$-" in *i* ) i=interactive ;; * ) i=not-interactive ;;
> > es
On Sat, Aug 27, 2022 at 10:21:08AM +1000, David wrote:
> Just sharing something that I tried, to shed some more light
> on this, in case that's useful ...
>
> $ foo() { case "$-" in *i* ) i=interactive ;; * ) i=not-interactive ;;
> esac ; echo $BASHPID $i ; }
> $ declare -fx foo
> $ foo
> 2415 int
On Sat, 27 Aug 2022 at 08:54, Tim Woodall wrote:
> On Fri, 26 Aug 2022, to...@tuxteam.de wrote:
> > On Fri, Aug 26, 2022 at 10:57:44AM -0400, Greg Wooledge wrote:
> I modified /etc/bash.bashrc to prove it was only being sourced in the
> second case above (it prints the value of PS1)
>
> And now I
On Fri, Aug 26, 2022 at 11:54:06PM +0100, Tim Woodall wrote:
> I modified /etc/bash.bashrc to prove it was only being sourced in the
> second case above (it prints the value of PS1)
>
> And now I can reproduce without -u
> $ bash -c :
> $ ( bash -c : )
> 'PS1='
> $ ( bash -c : ; : )
> $
I can't r
On Fri, 26 Aug 2022, to...@tuxteam.de wrote:
On Fri, Aug 26, 2022 at 10:57:44AM -0400, Greg Wooledge wrote:
[...]
There are also various hacks that are compiled into Debian's version
of bash [...]
At this moment, I'm kind of leaning toward one of those hacks being
triggered by your specifi
On Fri, Aug 26, 2022 at 10:57:44AM -0400, Greg Wooledge wrote:
[...]
> There are also various hacks that are compiled into Debian's version
> of bash [...]
> At this moment, I'm kind of leaning toward one of those hacks being
> triggered by your specific combination of factors.
That's the most
On Fri, Aug 26, 2022 at 02:51:47PM +0100, Tim Woodall wrote:
> The real Makefile has -euo pipefail
I have stopped reading and caring now. Good luck.
On Fri, Aug 26, 2022 at 02:40:55PM +0100, Tim Woodall wrote:
> But that's backwards, make is starting an interactive shell when its
> output is redirected. When I don't redirect make's output it works.
I thought you were piping in the original message. There is a difference
between a pipe, and a
On Fri, 26 Aug 2022 at 23:41, Tim Woodall wrote:
> On Fri, 26 Aug 2022, David wrote:
> > On Fri, 26 Aug 2022 at 22:14, wrote:
> >> And then, there's that other riddle: why is a shell invoked from a
> >> Makefile sourcing /etc/bash.bashrc in the first place?
> >
> > Hi, my understanding is that t
On Fri, 26 Aug 2022, David wrote:
On Fri, 26 Aug 2022 at 22:14, wrote:
On Fri, Aug 26, 2022 at 07:24:44AM -0400, Greg Wooledge wrote:
On Fri, Aug 26, 2022 at 08:17:10AM +0100, Tim Woodall wrote:
[...]
On Fri, Aug 26, 2022 at 11:04:25AM +0200, Thomas Schmitt wrote:
to...@tuxteam.de wrote:
On Fri, 26 Aug 2022, David wrote:
On Fri, 26 Aug 2022 at 22:14, wrote:
And then, there's that other riddle: why is a shell invoked from a
Makefile sourcing /etc/bash.bashrc in the first place?
Hi, my understanding is that the rule commands in the Makefile are run by
a shell, one for each li
On Fri, 26 Aug 2022 at 22:14, wrote:
> On Fri, Aug 26, 2022 at 07:24:44AM -0400, Greg Wooledge wrote:
> > On Fri, Aug 26, 2022 at 08:17:10AM +0100, Tim Woodall wrote:
[...]
> > On Fri, Aug 26, 2022 at 11:04:25AM +0200, Thomas Schmitt wrote:
> > > to...@tuxteam.de wrote:
> But all in all we're s
On Fri, 26 Aug 2022 at 22:14, wrote:
> And then, there's that other riddle: why is a shell invoked from a
> Makefile sourcing /etc/bash.bashrc in the first place?
Hi, my understanding is that the rule commands in the Makefile are run by
a shell, one for each line. The output stream of those comm
er PS1 is set is a *hack* and it will fail (giving false
> positives) if the user has exported the PS1 variable. Which some people
> do.
>
> > $ [ -z "${PS1:+x}" ] && echo "empty"
>
> The ":" gives a positive result if the variable is defined
On Fri, Aug 26, 2022 at 11:14:37AM +0100, Tim Woodall wrote:
> $ bash -uic 'echo done'
> bash: SUDO_USER: unbound variable
> bash: color_prompt: unbound variable
> done
> $
Cute. Mine's even weirder:
unicorn:~$ bash -uic 'echo done'
bash: SUDO_USER: unbound variable
bash: no: unbound variable
do
positives) if the user has exported the PS1 variable. Which some people
do.
> $ [ -z "${PS1:+x}" ] && echo "empty"
The ":" gives a positive result if the variable is defined but empty,
which may not be what you want. Dunno, hard to guess why anyone wou
On Fri, Aug 26, 2022 at 09:19:03AM +0100, Tim Woodall wrote:
[...]
Yes, I know how to fix it. That is straight forward. SUDO_USER and
SUDO_PS1 have similar issues, debian_chroot works in the presence of set
-u
I see.
But I don't understand why /etc/bash.bashrc is being sourced by make
w
On Fri, 26 Aug 2022 at 18:02, wrote:
> On Fri, Aug 26, 2022 at 08:17:10AM +0100, Tim Woodall wrote:
> > $ cat Makefile.test
> > SHELL := /bin/bash -u
> > MAKEFLAGS += --no-builtin-rules
> > .SUFFIXES:
> >
> > all:
> > echo done
> > $ make -f Makefile.test
> > echo done
> > done
> > $ make
On Fri, Aug 26, 2022 at 11:04:25AM +0200, Thomas Schmitt wrote:
> Hi,
>
> to...@tuxteam.de wrote:
> > Why {PS1:+x} rather than {PS1:-}?
>
> It seemed to be the nearest suitable variation which was similar to the
> proposal
> [ ${var+x} ]
[...]
Thanks :)
Cheers
--
t
signature.asc
Descripti
Hi,
to...@tuxteam.de wrote:
> Why {PS1:+x} rather than {PS1:-}?
It seemed to be the nearest suitable variation which was similar to the
proposal
[ ${var+x} ]
in
https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash
where one can see a nice table of ${VARIABLE.
On Fri, Aug 26, 2022 at 09:19:03AM +0100, Tim Woodall wrote:
[...]
> Yes, I know how to fix it. That is straight forward. SUDO_USER and
> SUDO_PS1 have similar issues, debian_chroot works in the presence of set
> -u
I see.
> But I don't understand why /etc/bash.bashrc is being sourced by make
>
On Fri, 26 Aug 2022, to...@tuxteam.de wrote:
On Fri, Aug 26, 2022 at 08:17:10AM +0100, Tim Woodall wrote:
$ cat Makefile.test
SHELL := /bin/bash -u
MAKEFLAGS += --no-builtin-rules
.SUFFIXES:
all:
echo done
$ make -f Makefile.test
echo done
done
$ make -f Makefile.test | cat
echo done
/
On Fri, Aug 26, 2022 at 10:01:06AM +0200, Thomas Schmitt wrote:
> Hi,
>
> > $ cat Makefile.test
> > SHELL := /bin/bash -u
> > [...]
> > /etc/bash.bashrc: line 7: PS1: unbound variable
> > [...]
> > Why do I get that unbound variable error?
>
> According to a comment in /etc/bash.bashrc it tests f
On Fri, Aug 26, 2022 at 08:17:10AM +0100, Tim Woodall wrote:
> $ cat Makefile.test
> SHELL := /bin/bash -u
> MAKEFLAGS += --no-builtin-rules
> .SUFFIXES:
>
> all:
> echo done
> $ make -f Makefile.test
> echo done
> done
> $ make -f Makefile.test | cat
> echo done
> /etc/bash.bashrc: line 7
1 - 100 of 1640 matches
Mail list logo
