Op 08-12-2020 om 15:12 schreef Chet Ramey:
> On 12/8/20 6:18 AM, Benno Schulenberg wrote:
>> Yes, but for translators that is too far back -- too much time passes
>> before the actual release happens.
>
> That doesn't make any sense. If there are any changed strings
Op 07-12-2020 om 20:39 schreef Chet Ramey:
> On 12/7/20 1:47 PM, Benno Schulenberg wrote:
>> It would be nice if the Translation Project would get a CC for
>> the rc1 or rc2 release of bash, not for the final release.
>
> I copied coordina...@translationproject.org for
&g
Hello Chet,
> The first public release of bash-5.1 is now available with the URLs
>
> ftp://ftp.cwru.edu/pub/bash/bash-5.1.tar.gz
> ftp://ftp.gnu.org/pub/gnu/bash/bash-5.1.tar.gz
It would be nice if the Translation Project would get a CC for
the rc1 or rc2 release of bash, not for the final re
On Wed, Feb 17, 2016, at 04:11, Bob Proulx wrote:
> Benno Schulenberg wrote:
> > For that to work, it requires having 'set suspend' in your
> > nanorc. (Which I don't have, because it annoys me when nano
> > drops into the background when I accidentally hit ^
On Tue, Feb 16, 2016, at 11:19, Bob Proulx wrote:
> [...] this is the perfect case for job control. No need for a
> second terminal. Here is an example. Use Control-Z to stop the
> foreground job.
For that to work, it requires having 'set suspend' in your
nanorc. (Which I don't have, because
On Mon, Nov 2, 2015, at 16:41, Chet Ramey wrote:
> On 10/19/15 3:07 PM, Benno Schulenberg wrote:
> > As the command synopses are gettextized only in order to allow
> > translators to translate *possible arguments*, there is no need to
> > gettextize them when a command
In the output of the 'help' command in any bash upto and including
4.4-beta, the possible arguments in most of the commands listed are
shown in lowercase, but for some they are in uppercase. Examples:
alias [-p] [name[=value] ... ]
break [n]
case WORD in [PATTERN [| PATTERN]...) COMMANDS ;
Hi,
In bash-4.4-beta the command names 'true' and 'false' have been
mistakenly translated in the Greek, Italian, Slovak and Indonesian
PO files. The latter two also mistakenly translate 'times'.
As the command synopses are gettextized only in order to allow
translators to translate possible arg
f1b2ff178cd4a743a12c1cf928a94b5be8ffcec8 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg
Date: Mon, 19 Oct 2015 14:03:37 +0200
Subject: [PATCH 1/2] CHANGES-4.4: remove an empty section 4, and pluralize "Change"
Signed-off-by: Benno Schulenberg
---
CHANGES-4.4 |3 +--
1 files changed, 1 insertions(+), 2
l service should be
From 4c4f3de6fbc3684915ef89ca7ba0922f8d8283cb Mon Sep 17 00:00:00 2001
From: Benno Schulenberg
Date: Mon, 19 Oct 2015 13:47:41 +0200
Subject: [PATCH] cd: add a missing bracket to the synopsis in the Info manual
Also, for clarity, move the bracket in the synopsis on the
man page (and im
Chet Ramey wrote:
> > I'm thinking about fairly frequent commits to a `bash-devel' sort of
> > tree. The question is whether or not enough people would be interested
> > in that to make the frequency worth it.
Anyone wanting to propose a patch would like to prepare it against the
most recent stat
Hi,
When using 'echo -n' or printf without a final \n, and then using
the Up and Down keys to walk through previous commands, bash can
get confused about its cursor position (or rather its prompt
position) and either leave some stray text in the middle of the
line, or overwrite part of its pr
Hi,
Bash's printf appears to ignore the \c backslash escape:
$ printf "before \c after \a"
before \c after $
$ type printf
printf is a shell builtin
Of course the Open Group's description of printf
(http://www.opengroup.org/onlinepubs/95399/utilities/printf.html)
does not specify that \c i
Hi,
The help text for echo describes the effect of the backslash escape
\c like this:
$ help echo | grep '\\c'
\c suppress trailing newline
But what it actually does is different:
$ echo -e "before \c after \a"
before $
It cancels all characters that come after it. The printf c
Chet Ramey wrote:
> I'm not sure why \r at the beginning and end of a message bothers
> translators
They don't really. So if the \r must be there, leave it in. It's
just that in general: the fewer control characters in a string, the
better. Less clutter, less room for error.
(What I'd really
Hi,
In the POT file for bash-3.2 there is one msgid that contains two
\r characters. Are these carriage returns necessary? If not, it
would be better to remove them, as they are awkward for translators
and are causing a mild indigestion on Launchpad at the moment
(which is Launchpad's fault,
Xuefer wrote:
> Bash Version: 3.2
> Patch Level: 15
>
> expected: cursor moves in the range of "echo abc", and the[n] beyond "c"
> actually: cursor moves in the range of "$ echo ab" (including b)
Please try again with patch level 17. With bash-3.2.17 I cannot
reproduce that behaviour here.
> Re
Joe Peterson wrote:
> Benno Schulenberg wrote:
> > On what terminal are you doing this? To what encoding is the
> > terminal set?
>
> Mainly xterm (version 225, at least in one case). And I have the
> utf8 option on. Does this set the encoding to the proper value,
>
Giraud wrote:
> Benno Schulenberg wrote:
> > Then try 'env -i bash --noprofile --norc'. If that
> > instance of the shell doesn't exhibit the problem, then you
> > know for sure it's something in the environment.
>
> Initially, after entering
Giraud wrote:
> Hmm, interesting.
Please don't top-post.
> Yes, I do have PROMPT_COMMAND set, it appears. However, if I
> unset it (and even also 'export PS1="foo "' to set PS1 to a
> simple string), the problem remains.
Then look at a new typescript, and see if that strange 1034h is
still th
Giraud wrote:
> The following prompt is set in my .bashrc (but the same behavior
> happens if I do not set it or set it to a simple string, so I
> don't think this matters):
>
> PS1="\[\033[33m\]\h-\u\[\033[36m\] [\w] (\!)\[\033[00m\] "
>
> PROMPT_COMMAND is not set.
Look at your typescript
Joe Peterson wrote:
> when using LAN=en_US.UTF-8 (anf we've verified same on
> en_GB.UTF-8).
Apart from LANG=en_US.UTF-8, what is the rest of your locale?
> There are two cases I came up with. If you up-arrow through your
> history, hit right-arrow (i.e. going "past" the end - even though
> the
Tristan Miller wrote:
> However, there still seems to be a problem when multibyte
> characters appear in the prompt in the last column of the
> terminal window. Specifically, when the last character in a line
> is multibyte, it is sometimes printed as "��".
>
> I initially thought that this was a t
Tristan Miller wrote:
> Bash Version: 3.2
> Patch Level: 9
Please try again with patch level 17. Patch 16 or 17 addresses
multibyte characters.
> Repeat-By:
> 1. PS1="\w\[\033[0m\]"
> 2. mkdir n̈
> (Note that the above is U+006E U+0308)
> 3. cd n̈
> (At this point
Sean Burke wrote:
> The Unicode normalization test data at
> http://www.unicode.org/Public/UNIDATA/NormalizationTest.txt
> contains many sequences of this sort.
> The first chara cter sequence, LATIN CAPITAL LETTER D WITH DOT
> ABOVE, does produce this problem.
> Paste it into the comma
Paul Jarc wrote:
> Benno Schulenberg <[EMAIL PROTECTED]> wrote:
> > Andreas Schwab wrote:
> >><http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_ch
> >>ap02.html#tag_02_09_01_01>:
> >>
> >> If a simple command results
Andreas Schwab wrote:
> Benno Schulenberg <[EMAIL PROTECTED]> writes:
> > $ set() { echo "My set $@" ;}
> > $ set params
> > My set params
> >
> > It just works.
>
> It's not supposed to. See
><http://www.opengroup.org/onlinepubs/
Clive Nicolson wrote:
> Is it posible to get a user function named set to be called in
> place of the special builtin set?
>
> ie
>
> set() { echo "My set $@" ;}
>
> set params
You haven't tried this?
$ set() { echo "My set $@" ;}
$ set params
My set params
It just works.
Also read the output o
Chet Ramey wrote:
> I apparently fixed
> it while making a seemingly unrelated change a couple of weeks
> ago. Try this patch.
First hunk fails against p15. When adjusting the patch for that
(see attached), it solves the problem here. Thanks.
Benno
--- lib/readline/display.c.orig 2007-04-11 1
Volkov Peter wrote:
> The issue was reported at http://bugs.gentoo.org/156292 and is
> still reproducible in bash-3.2 patch level 10 and with
> redisplay-cursor-patch.
>
> To save you time steps to reproduce the problem:
> 1. Set PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '
> 2. cd /us
Chet Ramey wrote:
> Benno Schulenberg wrote:
> > Volkov Peter wrote:
> >> In bash-3.2:
> >> ~/tmp/bash/bash-3.2 $ mkdir тест/
>
> Try the attached patch; it fixes the display problems for me.
To add to the chorus: that indeed fixes the cursor problem when
havin
Volkov Peter wrote:
> In bash-3.2:
> ~/tmp/bash/bash-3.2 $ mkdir тест/
> ~/tmp/bash/bash-3.2 $ cd тест/
> ~/tmp/bash/bash-3.2/тест $ ls
> ~/tmp/bash/bash-3.2/тест $ #
Same problem here (# is position of cursor):
[EMAIL PROTECTED] ~ $ mkdir ĉĉ
[EMAIL
manuel targa wrote:
> Qual`e' il comando che mi permette di sapere in che directory mi
> trovo???
pwd
Aŭ uzu:
export PS1='\[\e[001;[EMAIL PROTECTED] \[\e[001;034m\]\w \$\[\e[000m\]'
por ĉiam vidi kie vi estas.
Benno
___
Bug-bash mailing list
B
Chet Ramey wrote:
> Bruce Korb wrote:
> > $ unset LC_COLLATE
>
> If LC_COLLATE is unset, LC_ALL and LANG both affect the collating
> order.
Aha! So that is where the apparent "system default locale" comes
from.
$ locale | grep COLL
LC_COLLATE=POSIX
$ unset LC_COLLATE
$ locale | grep COLL
LC_CO
Benno Schulenberg wrote:
> Attached patch prints the builtin commands alphabetically per
> column and uses a total width of 80 characters.
Here is a better patch. It also puts a ">" in the last column
position of the strings that are longer than the available width.
To fi
Hi,
Currently the 'help' command prints the synopses of all the builtin
commands in two columns, but does this row by row, making it hard
to see whether a specific command is present or not, as the columns
aren't arranged alphabetically. Also, the text uses a total width
of only 70 character
Attached patch gettextizes a bunch of strings that were found
uninternationalized while skimming through all the *.def and *.c
files. The second patch does this also for siglist.c file.
The third patch removes the duplication of the command name from
the output of 'help', as this duplication
Hi,
None of the synopses of the 'set' command mentions the -E and -T
options. The first patch corrects this. The second patch brings
some texts printed by 'help' more in line with the man page: among
other things it corrects a mistake in the description of 'trap' and
removes a duplicate sen
Hi,
When doing 'info bash' and Enter, followed by '/shopt' and twice
Enter, one ends up in the middle of the description of 'declare',
instead of at the top of the page. Apparently texinfo contains a
bug: when a node contains a reference to itself, any reference
jumps to that reference inst
Hi,
Attached patch fixes the mistakes I've found so far in the texts
printed by the 'help' command. It adds a missing percent sign to
the synopsis of '%', corrects the description of the -p option of
'time', makes 'file' an optional argument in the synopsis of 'exec'
and removes a duplicate
Chet Ramey wrote:
> Benno Schulenberg wrote:
> > On the other hand, it looks like all of the message strings in
> > lib/malloc/watch.c are debugging messages, [...]
>
> Yes. The affected code is not compiled in by default unless
> DEBUG is defined, and that has to be tur
Hi,
While translating bash's messages, I noticed that some messages
haven't been gettextized. Attached patch fixes these -- just the
ones I happened to notice, I haven't done a full inspection.
The first patch also fixes a typo, and changes a trailing space to
a leading one (preferred by tra
Chet Ramey wrote:
> I will probably not make a bash-3.3 release, but may release the
> new translations in a single package before bash-4.0 comes out.
As a separate package? Hmm, strange, but okay.
If any of the strings change between 3.2 and 4.0, though, please
make 4.0-pre release several wee
Hi,
It seems that bash has never used the translations that were made at
http://www.iro.umontreal.ca/translation/registry.cgi?domain=bash .
At the moment Spanish and Turkish are completely up to date, and
Estonian is halfway -- will these translations make it into the
tarball for bash-3.3? Or
44 matches
Mail list logo
