On Mon, 15 Apr 2024 14:17:10 +0200, =?utf-8?B?0KHRgtGA0LDRhdC40ZrQsCDQoNCw0LTQu
NGb?= wrote:
> Just to clarify, this particular instance of this issue seems to be related t
> o
> terminfo.
>
> In general, as I stated earlier, the log message
>
> ... [program_name]: vfprintf %s NULL in
On Mon, Apr 15, 2024 at 02:25:04AM +, Jeremy Mates wrote:
> TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file
> exists therein. Also trying to read "none" (or maybe also "none.db" when
> the TERMINFO thing happens) from the current working directory might not
> be a good
Дана 24/04/15 02:25AM, Jeremy Mates написа:
> TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file
> exists therein. Also trying to read "none" (or maybe also "none.db" when
> the TERMINFO thing happens) from the current working directory might not
> be a good idea, if an
TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file
exists therein. Also trying to read "none" (or maybe also "none.db" when
the TERMINFO thing happens) from the current working directory might not
be a good idea, if an attacker can put naughty things into either of
those files
On Thu, Apr 11, 2024 at 10:10:20AM +0200, Eivind Eide wrote:
It is possible that I have missed important context here, but with a
bare environment with only essentials like $HOME defined and no
~/.terminfo directory (as opposed to an empty one), do the odd messages
still appear?
After
rm -rf
> It is possible that I have missed important context here, but with a
> bare environment with only essentials like $HOME defined and no
> ~/.terminfo directory (as opposed to an empty one), do the odd messages
> still appear?
After
rm -rf ~/.terminfo/
the message is gone (regardless of
On Thu, Apr 11, 2024 at 09:41:47AM +0200, Eivind Eide wrote:
>
> HOME="/home/eivind"
>
> That's the environmental variable that triggers the message if an
> empty ~/.terminfo/ directory is present in my home.
It is possible that I have missed important context here, but with a
bare environment
> UPDATE: If the ~/.terminfo/ directory EXIST in users home but the
> termcap file is missing, the behaviour returns.
> It's to late now, but I will do the tests and report back tomorrow.
And... The winner is:
HOME="/home/eivind"
That's the environmental variable that triggers the message if an
> Now I wanted to start testing environmental variables so I completely
> removed the ~/.terminfo/ directory, expecting the previous behavior to
> return. However, I cannot reproduce! I even tried rebooting, but no. I
> have no rational explanation for this.
UPDATE: If the ~/.terminfo/ directory
> Given 'if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT
> triggering the message', that implies that one of the other variables
> set would be triggering it, can you either figure out which one or
> show the list so someone else can try to replicate it please?
Yes, I would really
On 2024-04-09, Why 42? The lists account. wrote:
>
> On Sat, Apr 06, 2024 at 02:42:25PM +0200, Eivind Eide wrote:
>> After upgrading to 7.5 amd64 -stable (and all ports updated) I get
>> these messages in /var/log/messages. This is with bash from ports
>> inside tmux over SSH:
>>
>> tmux:
"Why 42? The lists account." writes:
Tumbler is something to do with D-Bus and is also a required
package by/for XFCE.
Yeah, Tumbler / tumblerd is a service, accessible via D-Bus, that
generates thumbnails for files, e.g. in ~/.cache/thumbnails or
equivalent.
(But i'm not an XFCE user
On 2024-04-09, Eivind Eide wrote:
>>The log message no longer appears after running
>>
>>cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/
>
> Indeed! After
> mkdir -p ~/.terminfo/t/
> cp /usr/share/terminfo/t/tmux-256color ~/.terminfo/t/
> (and the same for other termcaps
On Sat, Apr 06, 2024 at 02:42:25PM +0200, Eivind Eide wrote:
> After upgrading to 7.5 amd64 -stable (and all ports updated) I get
> these messages in /var/log/messages. This is with bash from ports
> inside tmux over SSH:
>
> tmux: vfprintf %s NULL in "%.*s"
> bash: vfprintf %s NULL in "%.*s"
>The log message no longer appears after running
>
>cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/
Indeed! After
mkdir -p ~/.terminfo/t/
cp /usr/share/terminfo/t/tmux-256color ~/.terminfo/t/
(and the same for other termcaps used)
those messages are gone from
Given
logger foo;xterm -tn xterm-256color -e ktrace -di /bin/ksh
the log message 'ksh: vfprintf %s NULL in "%.*s"' appears when
~/.terminfo/x/xterm/xterm-256color does not exist.
The log message no longer appears after running
cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/
and
On 2024-04-08, Eivind Eide wrote:
> 24/04/06 06:04PM, Stuart Henderson:
>> The fact that these all started hitting this with the same printf string
>> (including tmux, which is in base) makes me wonder if it's coming from a
>> library, the most likely being libcurses which was updated between 7.4
24/04/06 06:04PM, Stuart Henderson:
> The fact that these all started hitting this with the same printf string
> (including tmux, which is in base) makes me wonder if it's coming from a
> library, the most likely being libcurses which was updated between 7.4
> and 7.5 (which all of those use).
>
>
Дана 24/04/07 10:11AM, Stuart Henderson написа:
> Yes. It's very common though, especially when constructing strings for
> debug logging. I see this a lot with software in the GNOME ecosystem
> using sprintf for this.
Programmers who pass NULL to %s format specifier are writing incorrect code,
On 2024-04-06, Страхиња Радић wrote:
> Дана 24/04/06 06:04PM, Stuart Henderson написа:
>> The fact that these all started hitting this with the same printf string
>> (including tmux, which is in base) makes me wonder if it's coming from a
>> library, the most likely being libcurses which was
Дана 24/04/06 06:04PM, Stuart Henderson написа:
> The fact that these all started hitting this with the same printf string
> (including tmux, which is in base) makes me wonder if it's coming from a
> library, the most likely being libcurses which was updated between 7.4
> and 7.5 (which all of
On 2024-04-06, Страхиња Радић wrote:
> Дана 24/04/06 02:42PM, Eivind Eide написа:
>> tmux: vfprintf %s NULL in "%.*s"
>> bash: vfprintf %s NULL in "%.*s"
>> multitail: vfprintf %s NULL in "%.*s"
>> vim: vfprintf %s NULL in "%.*s"
>
> This happens in OpenBSD when a program passes NULL pointer to
Дана 24/04/06 02:42PM, Eivind Eide написа:
> tmux: vfprintf %s NULL in "%.*s"
> bash: vfprintf %s NULL in "%.*s"
> multitail: vfprintf %s NULL in "%.*s"
> vim: vfprintf %s NULL in "%.*s"
This happens in OpenBSD when a program passes NULL pointer to *printf family of
functions. The bug reports
After upgrading to 7.5 amd64 -stable (and all ports updated) I get
these messages in /var/log/messages. This is with bash from ports
inside tmux over SSH:
tmux: vfprintf %s NULL in "%.*s"
bash: vfprintf %s NULL in "%.*s"
multitail: vfprintf %s NULL in "%.*s"
vim: vfprintf %s NULL in "%.*s"
tmux:
24 matches
Mail list logo
