built-in printf returns success when integer is out of range

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux fnord42 6.1.25-1rodete1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.25-1rodete1

Re: built-in printf returns success when integer is out of range

$ /usr/bin/printf '%d\n' 111 && echo yes || echo no /usr/bin/printf: ‘111’: Numerical result out of range 9223372036854775807 no -- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "th

incorrect handling of invisible characters in prompt string

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: netbsdelf Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='netbsdelf' -DCONF_MACHTYPE='i386--netbsdelf' -DCONF_VENDOR='' -DLOCALEDIR='/usr/pkg/share/locale'

command completion

Before there was programmable completion, there was simply filename completion. Now we have smart completion, which you can turn off with complete -r. But that doesn't revert to simple filename completion. It still insists on doing command completion. That means that if it thinks that a

[Fwd: [KDE Bug 124960] konsole/bash must not execute CR unconfirmed prompt commands on exit signals]

From: schorpp To: bug-bash@gnu.org,[EMAIL PROTECTED] Subject: -see mail subject- Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu'

The yank-last-arg (_) command and comments

. -- --- Thomas Mellman Tel: +49/8233/389-037 Creative Telcom Solutions [EMAIL PROTECTED] Fax: +49/1212-5-115-48-103 ___ Bug-bash mailing list Bug-bash@gnu.org http

Re: Bug-bash Digest, Vol 47, Issue 9

[EMAIL PROTECTED] wrote: --- Message: 1 Date: Tue, 10 Oct 2006 16:08:05 -0500 From: mwoehlke [EMAIL PROTECTED] Subject: How to detect bash? To: bug-bash@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Anyone have any clever, VERY reliable

Re: Hidden files feature request

and so forth, I guess. Regards, Thomas signature.asc Description: Digital signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: readline: edit (mode:vi) means eol unreachable

problems). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Bash uses 100% CPU time (when started by su)

Configuration Information: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL

Re: shouldn't prompt printing be smarter?

(Sun console for instance). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Would bash ever use xterm color support as default?

the examples given are all hardcoded, and (given the limitation to specific terminal types) more/less work without requiring any modification to bash. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug

Misleading syntax in manual

The syntax for the for command is misleading, as although correct for bash, it is not POSIX-compliant. I am using GNU bash, version 3.2.48(1)-release (i486-pc-linux-gnu) The man page says: for name [ in word ] ; do list ; done which conflicts with the POSIX syntax definition, given in

Improving the manual (was: ${!vname} not documented)

for $! and find it), it was not accepted. I support that such a patch is installed, as it makes navigating in the manual easier for all those who don't know in which section to look for $!, for example. Regards, Thomas signature.asc Description: Digital signature

unicode aware printf \u and \U switches not supported

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc'

Re: manpage error-Arithmetic Evaluation of numbers with explicit base

Well OK, I understand. Still I think there should be a difference in the man page when it comes to brackets. When talking about arrays, the brackets are NOT an option but mandatory. (and it might be me being uneducated, but how to you print out the decimal equivalent of binary 11 without using

Re: manpage error-Arithmetic Evaluation of numbers with explicit base

, as there are multiple meanings for a poor little bracket ;- On Mon, 03/29, 2010 02:51:18PM, Greg Wooledge wrote: On Mon, Mar 29, 2010 at 02:22:35PM +0200, Thomas Bartosik wrote: Well OK, I understand. Still I think there should be a difference in the man page when it comes to brackets. When talking about

bad substitution: no closing `)' in $( #...

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd6.2 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd6.2' -DCONF_MACHTYPE='i386-portbld-freebsd6.2' -DCONF_VENDOR='portbld'

Pleac:

Hi, bash has only 0.43% examples at the pleac project. Pleac is the perl cookbook translated to other languages. It would be nice if someone could improve it: http://pleac.sourceforge.net/ Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de

edit-and-execute-command is appropriately named, weird

Hi all, In using bash over the years, I've been quite happy to be able to hit ctrl-x ctrl-e to pull up an editor when my input has grown too complicated. When using read -e for input, however, the behavior I find makes a lot less sense: the input line is still opened in an editor, but the result

Re: edit-and-execute-command is appropriately named, weird

Thomas wrote: Hi all, In using bash over the years, I've been quite happy to be able to hit ctrl-x ctrl-e to pull up an editor when my input has grown too complicated. When using read -e for input, however, the behavior I find makes a lot less sense: the input line is still opened in an editor

Re: edit-and-execute-command is appropriately named, weird

is hooked up (which should be any day now...). On Sat, May 28, 2011 at 3:42 PM, Chet Ramey chet.ra...@case.edu wrote: On 5/27/11 6:20 PM, David Thomas wrote: Hi Chet, Thank you for the response, and the attempt at assistance. I was unaware of the POSIX specifications relating to editing modes

[PATCH] add #if defined(JOB_CONTROL) around job_control in execute_cmd.c

Hello, In bash-4.2 in execute_cmd.c there is a usage of job_control that isn't enclosed in #if defined(JOB_CONTROL) / #endif. This causes a compile failure on Minix since job_control is only defined if JOB_CONTROL is defined. Patch attached. -Thomas --- execute_cmd.c.orig Fri Jun 3 13:34:42

Re: Edit vs delete a running script. Why difference?

On Jan 18, 5:22 am, Greg Wooledge wool...@eeg.ccf.org wrote: On Wed, Jan 18, 2012 at 01:19:20PM +0900, Teika Kazura wrote: If the entire script is read at invocation, then why should / does modification affect? Is it a bug? The entire script *isn't* read at invocation.  Bash just reads a

Misleading text at start of manual

(Checked against bash 4.2; for some reason, the manual on gnu.org is only 4.1.) The top node, Bash Features, says: The following menu breaks the features up into categories based upon which one of these other shells inspired the feature. But the following menu doesn't seem to bear that out.

Patch for examples/loadables/ln.c: support for -n option

to the sources if you think it's worth it. Kind regards, Julien From dff9b244b233415d5081c3e4b40500e01929c74a Mon Sep 17 00:00:00 2001 From: Julien Thomas jtho...@exosec.fr Date: Mon, 27 May 2013 17:45:11 +0200 Subject: [PATCH 1/3] ln: Whitespace cleanup, remove tabulations --- ln.c | 61

Bug in bash(1)

:58.541953745 +0200 @@ -7307,13 +7307,6 @@ .BR SIGHUP . If no .I jobspec -is present, and neither the -.B \-a -nor the -.B \-r -option is supplied, the \fIcurrent job\fP is used. -If no -.I jobspec is supplied, the .B \-a option means to remove or mark all jobs; the -- Thomas Hood

Bogus SIGPIPE bug

likely a distro-specific bug? Info: $ bash --version GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu) rpm -q -a|grep bash bash-3.2-147.9.13 $ cat /etc/issue Welcome to SUSE Linux Enterprise Server 11 SP2 (x86_64) - Kernel \r (\l). I attach the test program I use. -- Thomas Hood RAAF

When a hashed pathname is deleted, search PATH

Tested in bash 4.3. $ foo ... a command is run $ hash hits command 0 /home/rrt/bin/foo $ rm `which foo` $ which foo /usr/bin/foo $ foo bash: /home/rrt/bin/foo: No such file or directory Why doesn't bash just remove the hashed path and do a normal PATH search? I have to remove it manually. --

Re: When a hashed pathname is deleted, search PATH

On 14 March 2014 18:23, Chet Ramey chet.ra...@case.edu wrote: On 3/14/14 12:11 PM, Reuben Thomas wrote: Tested in bash 4.3. $ foo ... a command is run $ hash hits command 0 /home/rrt/bin/foo $ rm `which foo` $ which foo /usr/bin/foo $ foo bash: /home/rrt/bin/foo

Re: When a hashed pathname is deleted, search PATH

On 15 March 2014 18:23, Chet Ramey chet.ra...@case.edu wrote: It's not been a problem, really. The existence of the `checkhash' option has been enough. How often do you remove binaries in directories in $PATH? Fairly often: I frequently rename or retire scripts in my per-user bin directory.

Re: When a hashed pathname is deleted, search PATH

On 17 March 2014 14:12, Chet Ramey chet.ra...@case.edu wrote: On 3/15/14 2:44 PM, Reuben Thomas wrote: On 15 March 2014 18:23, Chet Ramey chet.ra...@case.edu mailto:chet.ra...@case.edu wrote: It's not been a problem, really. The existence of the `checkhash' option has been

Re: When a hashed pathname is deleted, search PATH

On 17 March 2014 20:30, Chet Ramey chet.ra...@case.edu wrote: On 3/17/14 10:17 AM, Dave Rutherford wrote: On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey chet.ra...@case.edu wrote: On 3/15/14 2:44 PM, Reuben Thomas wrote: On 15 March 2014 18:23, Chet Ramey chet.ra...@case.edu

Re: When a hashed pathname is deleted, search PATH

On 18 March 2014 08:04, Linda Walsh b...@tlinx.org wrote: Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check the

Reverse incremental search provoking errors

for a while. Best regards Thomas

Re: read -e does not restore terminal settings correctly when interrupted if a trap is set

Yep, that fixed the problem, thank you ! 2014-09-08 20:46 GMT+02:00 Chet Ramey chet.ra...@case.edu: On 9/7/14, 6:40 PM, micka...@gmail.com wrote: Bash Version: 4.3 Patch Level: 24 Release Status: release Description: Given the following script (test.sh) : #!/bin/bash

extglob features less useful since shell scripts turn them off

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'

Please improve documentation of history -a

At least in bash 4.3, the documentation for history -a says: Append the new history lines (history lines entered since the beginning of the current Bash session) to the history file. This is unfortunately misleading, since it suggests that the technique of adding history -a

Feature proposal/request: input line highlighting

supply a patch if I had a clue where to hook it in... Thanks and kind regards, Thomas

Re: Fwd: Re: Feature proposal/request: input line highlighting

On 11 Jun 2015 18:10, Thomas Wolff wrote: as opposed to having a fancy colored prompt, I would like to be able to set up coloring of the whole bash command input line (but not the following command output). This could be achieved by adding a variable like AFTERPROMPT_COMMAND which

Re: Default time for unmarked history lines

On 7 January 2016 at 20:07, Eduardo A. Bustamante López wrote: > (2) The history should be ordered monotonically (increasing?) > ​Yes, and it's not at the moment (or wasn't, until I added timestamps to every line in my history), because the lines at the start of the history,

Re: Default time for unmarked history lines

On 8 January 2016 at 04:21, Eduardo A. Bustamante López wrote: > > I now understand your points. > ​Thanks very much for taking a look at this.​ > dualbus@hp ...src/gnu/bash % cat ~/.bash_history > echo 1 > #1452197044 > echo a; sleep 1 > #1452197045 >

Re: Default time for unmarked history lines

On 11 January 2016 at 14:22, Chet Ramey wrote: > For a history file without any timestamps, using > the current default and setting the history entry timestamp to the current > time is more appropriate. > ​Why is that? The only similar thing I can think of is file systems,

Fwd: Default time for unmarked history lines

[ ​Forwarding reply erroneously not sent to the list.]​ On 15 January 2016 at 15:26, Chet Ramey <chet.ra...@case.edu> wrote: > On 1/11/16 11:54 AM, Reuben Thomas wrote: > > On 11 January 2016 at 14:22, Chet Ramey <chet.ra...@case.edu > > <mailto:

Re: Fwd: Default time for unmarked history lines

On 18 January 2016 at 22:21, Chet Ramey <chet.ra...@case.edu> wrote: > On 1/18/16 11:53 AM, Reuben Thomas wrote: > > > So, how about instead interpreting a missing/0 date as a NaD (Not A > Date), > > rather as readline does anyway with time 0, and providing a slightly

Time to increase the defaults for history size?

The default HISTSIZE and HISTFILESIZE have been set for as long as I can remember (and the repo only seems to back to bash 3.2). For those concerned about privacy or security, 500 lines is probably too much. For those concerned about disk space, it's hard to come up with a sensible default. My

Running bash under valgrind gives "invalid free()"

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517 ​I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and in a build of 4.4 from source on my Ubuntu system. ​As stated in the bug report, the bug causes problems beyond bash, as it causes build systems to think that

Re: Running bash under valgrind gives "invalid free()"

​O​ n 12 April 2017 at 15:49, Chet Ramey wrote: > > It's a false positive, or a bug in valgrind. I took a quick look. There's > one place in this code path where free() gets called. Here's the trace: > ​[analysis snipped] Thanks very much, looks like it's time for me to

Re: Running bash under valgrind gives "invalid free()"

​O​ n 12 April 2017 at 14:50, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/12/17 8:57 AM, Reuben Thomas wrote: > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517 > > > > ​I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and > &

Re: Running bash under valgrind gives "invalid free()"

On Apr 12, 2017 4:56 PM, "Chet Ramey" wrote: [snip] > Maybe update the Debian bug report you cited as well. There's still stuff > there from 2005. The report is from December 2016. I can't find "2005" in the page. I'll certainly send an update to point to the upstream

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 21:17, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 3:57 PM, Reuben Thomas wrote: > > > Meanwhile, in the valgrind bug report, Mark Wielaard observed: > > > > "I think the problem is that bash not only has its own malloc/free

Leaks detected by valgrind

Here they are. I guess you probably won't care about them as as far as I can see they are all one-off allocations at initialization: ==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249 ==1289==at 0x4C2DB2F: malloc (in

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 09:15, Reuben Thomas <r...@sc3d.org> wrote: > > Having confirmed Chet's analysis with a few printfs added to bash (i.e. > just to check the address being allocated and the one complained about were > the same) I've filed a bug report against valgrind: >

Re: Running bash under valgrind gives "invalid free()"

On 12 April 2017 at 17:58, Hanno Böck <ha...@hboeck.de> wrote: > On Wed, 12 Apr 2017 14:59:26 +0100 > Reuben Thomas <r...@sc3d.org> wrote: > > > ​frequently, it's the only tool that shows up bugs of this sort, as > > it's rather more powerful than a debugging

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 16:46, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 11:41 AM, Reuben Thomas wrote: > > > ​This is not the result I obtained. I simply ran gdb on the bash binary, > > valgrind was not involved.​ > > If you didn't build the binary yours

Re: Running bash under valgrind gives "invalid free()"

On 12 April 2017 at 15:49, Chet Ramey wrote: > > It's a false positive, or a bug in valgrind. I took a quick look. There's > one place in this code path where free() gets called. ​Julian Seward (valgrind author) pointed out:​ " ​…​ what you report is symptomatic of bash

Re: Running bash under valgrind gives "invalid free()"

​O​ n 13 April 2017 at 16:27, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 11:18 AM, Reuben Thomas wrote: > > On 13 April 2017 at 16:11, Chet Ramey <chet.ra...@case.edu > > <mailto:chet.ra...@case.edu>> wrote: > > > > > > I see n

Re: Running bash under valgrind gives "invalid free()"

​O​ n 13 April 2017 at 15:33, Reuben Thomas <r...@sc3d.org> wrote: > On 12 April 2017 at 15:49, Chet Ramey <chet.ra...@case.edu> wrote: > >> >> It's a false positive, or a bug in valgrind. I took a quick look. There's >> one place in this code path where free

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 16:11, Chet Ramey wrote: > > I see no reason why, since all of these things are defined in the same > file and are statically linked, `free' would resolve to the glibc free > when malloc resolves to the bash malloc. So this is the real problem?​ ​Do

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 22:05, Reuben Thomas <r...@sc3d.org> wrote: > > On 13 April 2017 at 21:17, Chet Ramey <chet.ra...@case.edu> wrote: > >> On 4/13/17 3:57 PM, Reuben Thomas wrote: >> >> > Meanwhile, in the valgrind bug report, Mark Wielaard observed: &

Sequence Brace Expansion Crash

From: thomas To: bug-bash@gnu.org Subject: Sequence Brace Expansion Crash Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE

failglob handling

line 2: no match: /foo/bar/* > alive > $ echo "set -e; shopt -s failglob; echo /foo/bar/*; echo alive; " | sed 's:; > :\n:g' | bash > bash: line 3: no match: /foo/bar/* > $ -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature

Bash will continue executing main code path instead of current code path on error

test.sh: line 5: bar=${${foo}_blah}: bad substitution I run after the failing_function! Rest of the script Is my expectation wrong? I am really wondering that the script will continue but not in the current if clause... Tested with: > GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu) --

[PATCH] Fix \H: Use getaddrinfo to get full hostname

At the moment, \h and \H used in prompt PS1 or PS2 will actually return the same value while manpage claims that \h should return hostname up to the first '.' (like `hostname`) and \H should return full hostname (like `hostname -f`). This commit will make bash use the same API like hostname

Re: [PATCH] Fix \H: Use getaddrinfo to get full hostname

(no FQDN) and set domain option in /etc/resolv.conf for example for FQDN. But maybe I am missing something. Thanks. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature

Re: [PATCH] Fix \H: Use getaddrinfo to get full hostname

ack to bash: So you are rejecting this patch, right? Maybe update man page at least to clarify that "\H" in contrast to "\h" is supposed to return the same value but _unfiltered_? Thanks. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 584

Re: [PATCH] Fix \H: Use getaddrinfo to get full hostname

like it, but our opinions only matter to us. OK :( Thank you for the explanation! -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature

Typo in documentation (e.g. man page): 'abd' -> 'and'

Hello, I noticed a small typo in the documentation on conditional expressions. The typo is visible in the man page bash(1), where it says: The test abd [ commands determine their behavior based on Most likely, 'abd' should be 'and' instead. Greetings, Thomas Fischer

Re: bug-bash Digest, Vol 218, Issue 13

On 1/10/21 6:00 PM, bug-bash-requ...@gnu.org wrote: Message: 3 Date: Sun, 10 Jan 2021 16:49:50 +0100 From: Ángel To: bug-bash@gnu.org Subject: Re: non-executable files in $PATH cause errors Message-ID: <94646752576f053515ac2ba4656fe0c895f348ce.ca...@16bits.net> Content-Type:

Bash symlink not followed as expected.

Hey All, Not sure if this is a bug but logging anyway just in case. Rgds, Thomas * The version number and release status of Bash (e.g., 2.05-release) o GNU bash, version 3.00.16(1)-release-(i386-pc-solaris2.10) * The machine and OS that it is running on (you may run /bashversion

accents

='/Users/thomas/Administration-ordinateur/autoinstall/macports/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I/Users/thomas/Administration-ordinateur/autoinstall/macports/include -pipe -O2 -arch x86_64 uname output: Darwin tDeContes-fixe.local 10.7.0

Re: accents

Le 9 mai 2011 à 20:21, Greg Wooledge a écrit : On Mon, May 09, 2011 at 04:46:14PM +0200, Thomas De Contes wrote: Description: 1 when i do PS1=# $PS1 then I have problems since there is some accents in my command lines : What is the value of PS1 before you prepend ampersand-hash-space

Re: accents

Le 16 mai 2011 à 17:02, Chet Ramey a écrit : On 5/9/11 10:46 AM, Thomas De Contes wrote: 1 - execute PS1=# $PS1 - drag drop the file with the accent - use top arrow and bottom arrow to move in the history : at each time you move on the line containing an accent, it eats one character

Re: accents

Le 25 août 2011 à 14:36, Greg Wooledge a écrit : On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote: BTW, Thomas -- what is the Character that comes after 'De' in your name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode. (it is NBSP (for address book)) RFC

Re: accents

know when it will be available ?) -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/

Re: accents

characters to be displayed correctly (Is it correct english enough ?) -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/

Tilde (~) in bash(1) is typeset incorrectly as Unicode character

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection

Re: Confusing documentation of `ENV` in section "Bash variables"

On Wed, 23 Sep 2020 at 14:24, Chet Ramey wrote: > "Expanded and executed similarly to BASH_ENV when an interactive shell is > invoked in POSIX Mode." > Yes, that's better than my suggestions, thanks! -- https://rrt.sc3d.org

Confusing documentation of `ENV` in section "Bash variables"

The documentation says: 'ENV' Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode (*note Bash POSIX Mode::). However, as described elsewhere in the manual, BASH_ENV is used specifically for non-interactive shells, whereas ENV is used specifically for interactive shells.