Re: Does "LC_ALL=C" work on all shells?

[Max Nikulin]

On 16/02/2024 23:35, Franco Martelli wrote:

On 16/02/24 at 03:03, Max Nikulin wrote:

 LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr


here seems to override, tested twice with "it" and "it_IT.UTF-8":

~# env LC_ALL=C LANGUAGE=it script -T ~/test.time -a ~/test.script


You tested with LC_ALL=C, not with LC_ALL=C.UTF-8. It has been discussed 
that behavior of gettext in respect to LANGUAGE is different.


I am against "C" locale in Debian official docs since it may mangle 
output. I have posted it already:


LC_ALL=C ls /tmp/it/
''$'\303\250'

LC_ALL=C.UTF-8 ls /tmp/it/
è

root@itek:~# env LC_ALL=C LANGUAGE=it_IT.UTF-8 script -T ~/test.time -a 
~/test.script


Again, LANGUAGE value is a list of *languages*, not a locale like for 
LANG or LC_*. LANGUAGE can be it:en_US:en, while this value is invalid 
for LC_ALL. Do not confuse these variables.


Try to add "export LC_ALL=it_IT.UTF-8" to .bashrc and e.g."date" in 
the script session.


Yes, the messages are localized to it_IT.UTF-8 into the "script" 
session, however users that have set LC_ALL variable into .bashrc I 
suppose already know what are they doing.


They just noticed that such variable exists and added to their configs. 
My colleague was bitten by LC_ALL. Is was a surprise when a database 
started to use "," instead of "." as decimal separator and it took 
enough time to find what caused drastic lost of precision. LC_ALL was 
set by the system administrator in ~/.bashrc.


I like the idea to *suggest* people to use English locale for upgrades 
if they are comfortable with it. It will help for searching web and 
during discussions. However I believe that a UTF-8 locale is safer and 
better nowadays. I hope, there is no mistakes any more:


LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE

or its equivalent for user shell executed inside "script" session. I am 
unsure if locale of "script" command can be an issue.

Re: Does "LC_ALL=C" work on all shells?

[Franco Martelli]

On 16/02/24 at 17:44, Greg Wooledge wrote:


If my guess is correct, then I don't support the plan to modify the
Debian documentation to suggest that everyone log their dist-upgrades
in English "because if something goes wrong you will probably ask for
help from an English speaker".  There are way too many layers of
assumptions there.


No it wasn't for this argument that I wrote:


"I think that a recorded session with the output of the commands in
English is better then a localized session for debugging purposes."


In the paragraph in question ¹  I read:

"It is strongly recommended that you use the /usr/bin/script program to 
record a transcript of the upgrade session. Then if a problem occurs, 
you will have a log of what happened, and if needed, can provide exact 
information in a bug report. To start the recording, type:"


Therefore I ran "script" session to upgrade to stable 12.5, then I saw 
that the output of "apt" was localized to my native language. So I 
thought: How can I provide exact information in a bug report if I've 
only localized messages?


For this reason I've asked for feedback here before to propose a change 
to the syntax to the "script" command that IMHO it'd be:


# env LC_ALL=C.UTF-8 script -T ~/upgrade-bookwormstep.time -a 
~/upgrade-bookwormstep.script


or at the place of LC_ALL to use instead LC_MESSAGES as Teemu wrote:

On 16/02/24 at 08:13, Teemu Likonen wrote:

To change programs' output messages to English LC_MESSAGES=C is often
enough. Sometimes LC_TIME and LC_NUMERIC are required too.


but it seems may have drawbacks if other variables are involved.
From the manual page of "script" command the -t option is deprecated in 
favor of -T and the above command has the advantage to be executable in 
all shells (thank to your feedback). A change is required however and 
the command proposed seems to me an improvement.




On Fri, Feb 16, 2024 at 05:35:11PM +0100, Franco Martelli wrote:

however users that have set LC_ALL variable into .bashrc I suppose already
know what are they doing.


No.  No, they do not.  They may *think* they do.  They do not.


Ahah OK they do not.


¹ 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#record-session

--
Franco Martelli

Re: Does "LC_ALL=C" work on all shells?

[tomas]

On Fri, Feb 16, 2024 at 11:44:21AM -0500, Greg Wooledge wrote:
> On Fri, Feb 16, 2024 at 05:35:04PM +0100, Franco Martelli wrote:
> > It was stated here:
> > https://lists.debian.org/debian-user/2024/02/msg00592.html
> 
> "I think that a recorded session with the output of the commands in
> English is better then a localized session for debugging purposes."
> 
> I have trouble following your reasoning there.  Do you mean that you
> expect they'll hand over the logs to *someone else* to debug, instead
> of reading it themselves?  I mean, that may be true, but you certainly
> didn't state it.  That leaves me needing to guess.

There's also looking up errors on a search engine. English texts do
have a higher probability of a meaningful hit.

But yes, it's complicated, to say the least (a case in point: my main
(not my native) language is currently German, but I vastly prefer
error messages in English).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Fri, Feb 16, 2024 at 05:35:04PM +0100, Franco Martelli wrote:
> It was stated here:
> https://lists.debian.org/debian-user/2024/02/msg00592.html

"I think that a recorded session with the output of the commands in
English is better then a localized session for debugging purposes."

I have trouble following your reasoning there.  Do you mean that you
expect they'll hand over the logs to *someone else* to debug, instead
of reading it themselves?  I mean, that may be true, but you certainly
didn't state it.  That leaves me needing to guess.

If my guess is correct, then I don't support the plan to modify the
Debian documentation to suggest that everyone log their dist-upgrades
in English "because if something goes wrong you will probably ask for
help from an English speaker".  There are way too many layers of
assumptions there.


On Fri, Feb 16, 2024 at 05:35:11PM +0100, Franco Martelli wrote:
> however users that have set LC_ALL variable into .bashrc I suppose already
> know what are they doing.

No.  No, they do not.  They may *think* they do.  They do not.

Re: Does "LC_ALL=C" work on all shells?

[Franco Martelli]

On 16/02/24 at 13:17, Greg Wooledge wrote:

On Fri, Feb 16, 2024 at 09:13:40AM +0200, Teemu Likonen wrote:

In my opinion it's often too much to set LC_ALL=C because it changes
charset to ASCII (LC_CTYPE).


It depends on what you're doing, of course.  If the purpose is to
normalize error messages so that you can report your issue to an
English-only mailing list, and if LC_ALL=C doesn't mangle the
output beyond recognition, then it might be good enough.

The OP of this thread seemed to have a goal of altering Debian
documentation to have *everyone* performing a dist-upgrade run
their dist-upgrade sessions under LC_ALL=C for reasons that I
can't remember (or which weren't stated).  I'm uncertain what the
larger goal is there -- many of these users would probably have
difficulty reading their own session logs afterward.



It was stated here:
https://lists.debian.org/debian-user/2024/02/msg00592.html

--
Franco Martelli

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Fri, Feb 16, 2024 at 09:13:40AM +0200, Teemu Likonen wrote:
> In my opinion it's often too much to set LC_ALL=C because it changes
> charset to ASCII (LC_CTYPE).

It depends on what you're doing, of course.  If the purpose is to
normalize error messages so that you can report your issue to an
English-only mailing list, and if LC_ALL=C doesn't mangle the
output beyond recognition, then it might be good enough.

The OP of this thread seemed to have a goal of altering Debian
documentation to have *everyone* performing a dist-upgrade run
their dist-upgrade sessions under LC_ALL=C for reasons that I
can't remember (or which weren't stated).  I'm uncertain what the
larger goal is there -- many of these users would probably have
difficulty reading their own session logs afterward.

Re: Does "LC_ALL=C" work on all shells?

[Teemu Likonen]

* 2024-02-15 21:17:44+0100, Franco Martelli wrote:

> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?

LC_ALL overrides LC_* variables. It's easy to test:

$ locale
LANG=fi_FI.UTF-8
LANGUAGE=fi
LC_CTYPE="fi_FI.UTF-8"
LC_NUMERIC="fi_FI.UTF-8"
LC_TIME="fi_FI.UTF-8"
LC_COLLATE="fi_FI.UTF-8"
LC_MONETARY="fi_FI.UTF-8"
LC_MESSAGES=C
LC_PAPER="fi_FI.UTF-8"
LC_NAME="fi_FI.UTF-8"
LC_ADDRESS="fi_FI.UTF-8"
LC_TELEPHONE="fi_FI.UTF-8"
LC_MEASUREMENT="fi_FI.UTF-8"
LC_IDENTIFICATION="fi_FI.UTF-8"


$ LC_ALL=C locale
    LANG=fi_FI.UTF-8
    LANGUAGE=fi
    LC_CTYPE="C"
LC_NUMERIC="C"
    LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

$ LC_ALL=C.UTF-8 locale
LANG=fi_FI.UTF-8
LANGUAGE=fi
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
    LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=C.UTF-8

In my opinion it's often too much to set LC_ALL=C because it changes
charset to ASCII (LC_CTYPE).

To change programs' output messages to English LC_MESSAGES=C is often
enough. Sometimes LC_TIME and LC_NUMERIC are required too.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: Does "LC_ALL=C" work on all shells?

[Max Nikulin]

On 16/02/2024 09:34, David Wright wrote:


Yes, LC_ALL=C will override all the locale variables,
but LC_ALL=C.UTF-8 will not:


It is documented in

2.3.3 Specifying a Priority List of Languages
(info "(gettext) The LANGUAGE variable")
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

however you may still prefer

 LC_ALL=C.UTF-8 LANGUAGE=

due to

 touch /tmp/it/è

 LC_ALL=C.UTF-8 ls /tmp/it/
 è

     LC_ALL=C ls /tmp/it/
 ''$'\303\250'

Re: Does "LC_ALL=C" work on all shells?

[David Wright]

On Thu 15 Feb 2024 at 21:17:44 (+0100), Franco Martelli wrote:
> On 15/02/24 at 03:28, Max Nikulin wrote:
> > > # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> > > ~/upgrade-bookwormstep.script
> > 
> > Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some
> > python scripts (unrelated to Debian upgrade however) failed trying
> > to log e.g. non-ascii file paths, etc.
> > 
> > I would reset LANGUAGE as well otherwise some programs may use
> > localized messages.
> > 
> > Finally, some users might have LC_ALL (despite it is not
> > recommended) or LANGUAGE set in a file like ~/.bashrc. That is why
> > the following approach may be more reliable. Run commands within
> > the "script" session
> > 
> >      LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
> > 
> > with a note concerning csh. To affect messages generated by shell
> > itself, "export" is separated from setting of the variables.
> 
> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings? On my
> system I have:
> 
> ~$ env | grep LANG
> LANGUAGE=
> LANG=it_IT.UTF-8

BTW, you can also print locale information with:

  $ locale
  LANG=C.UTF-8
  LANGUAGE=
  LC_CTYPE=en_GB.UTF-8
  LC_NUMERIC="C.UTF-8"
  LC_TIME="C.UTF-8"
  LC_COLLATE="C.UTF-8"
  LC_MONETARY="C.UTF-8"
  LC_MESSAGES="C.UTF-8"
  LC_PAPER="C.UTF-8"
  LC_NAME="C.UTF-8"
  LC_ADDRESS="C.UTF-8"
  LC_TELEPHONE="C.UTF-8"
  LC_MEASUREMENT="C.UTF-8"
  LC_IDENTIFICATION="C.UTF-8"
  LC_ALL=
  $ 

> and LC_ALL=C override the LANG setting when used inline of the
> command. This approach is to cover all cases, my goal is to do
> apt/apt-get commands output in English when they are executed into a
> "script" session.

Yes, LC_ALL=C will override all the locale variables,
but LC_ALL=C.UTF-8 will not:

  $ LC_ALL=C.UTF-8 LANGUAGE=it LANG=it_IT.UTF-8 aptitude why firefox-esr
  i   firefox-esr-l10n-en-gb Dipende firefox-esr (< 115.7.0esr-1~deb11u1.1~)
  $ LC_ALL=C LANGUAGE=it LANG=it_IT.UTF-8 aptitude why firefox-esr
  i   firefox-esr-l10n-en-gb Depends firefox-esr (< 115.7.0esr-1~deb11u1.1~)
  $ 

Cheers,
David.

Re: Does "LC_ALL=C" work on all shells?

[Max Nikulin]

On 16/02/2024 03:17, Franco Martelli wrote:

On 15/02/24 at 03:28, Max Nikulin wrote:


 LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE


Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?


Sorry, my bad. Of course

LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE


and LC_ALL=C override the LANG setting when used inline of the command.



LC_ALL does not override LANGUAGE. Try e.g.

LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr

# env LC_ALL=C script -T ~/upgrade-bookwormstep.time -a 
~/upgrade-bookwormstep.script


Try to add "export LC_ALL=it_IT.UTF-8" to .bashrc and e.g."date" in the 
script session.

Re: Does "LC_ALL=C" work on all shells?

[Franco Martelli]

Thanks Max,

On 15/02/24 at 03:28, Max Nikulin wrote:
# env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a 
~/upgrade-bookwormstep.script


Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some python 
scripts (unrelated to Debian upgrade however) failed trying to log e.g. 
non-ascii file paths, etc.


I would reset LANGUAGE as well otherwise some programs may use localized 
messages.


Finally, some users might have LC_ALL (despite it is not recommended) or 
LANGUAGE set in a file like ~/.bashrc. That is why the following 
approach may be more reliable. Run commands within the "script" session


     LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE

with a note concerning csh. To affect messages generated by shell 
itself, "export" is separated from setting of the variables.


Doesn't LC_ALL=C setting override LANG or LANGUAGE settings? On my 
system I have:


~$ env | grep LANG
LANGUAGE=
LANG=it_IT.UTF-8

and LC_ALL=C override the LANG setting when used inline of the command. 
This approach is to cover all cases, my goal is to do apt/apt-get 
commands output in English when they are executed into a "script" 
session. Thank to Greg's contribute I think I've reached it:



On 14/02/24 at 21:55, Greg Wooledge wrote:

The man page says:

-t[file], --timing[=file]
Output timing data to standard error, or to file when given. This
option is deprecated in favour of --log-timing where the file
argument is not optional.

And:

-T, --log-timing file
Log timing information to the file. Two timing file formats are
supported now. The classic format is used when only one stream
(input or output) logging is enabled. The multi-stream format is
used on --log-io or when --log-in and --log-out are used together.
See also --logging-format.

One of these paragraphs should give a solution that avoids needing 2>.


The following "script" command syntax should work on all shells (tested 
only in Bash):


# env LC_ALL=C script -T ~/upgrade-bookwormstep.time -a 
~/upgrade-bookwormstep.script



--
Franco Martelli

Re: Does "LC_ALL=C" work on all shells?

[Max Nikulin]

On 14/02/2024 23:11, Franco Martelli wrote:
Well, I'll go with env command syntax for shells portability. I was 
asking this because I want to suggest a change to the DDP (Debian 
Documentation Project) members for the releases notes documentation ¹


# env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a 
~/upgrade-bookwormstep.script


Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some python 
scripts (unrelated to Debian upgrade however) failed trying to log e.g. 
non-ascii file paths, etc.


I would reset LANGUAGE as well otherwise some programs may use localized 
messages.


Finally, some users might have LC_ALL (despite it is not recommended) or 
LANGUAGE set in a file like ~/.bashrc. That is why the following 
approach may be more reliable. Run commands within the "script" session


LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE

with a note concerning csh. To affect messages generated by shell 
itself, "export" is separated from setting of the variables.

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Wed, Feb 14, 2024 at 09:45:52PM +0100, Franco Martelli wrote:
> A new question arise spontaneously: how can csh users run a "script" saved
> session using "scriptreplay" command? In the §4.4.1 "Recording the session"
> paragraph ¹  I see this syntax:
> 
> # scriptreplay ~/upgrade-bookwormstep.time ~/upgrade-bookwormstep.script
> 
> That it uses both stderr and stdout saved separately. Maybe they have to use
> another syntax or forcibly run a Bourne shell as you wrote below:

The man page says:

   -t[file], --timing[=file]
   Output timing data to standard error, or to file when given. This
   option is deprecated in favour of --log-timing where the file
   argument is not optional.

And:

   -T, --log-timing file
   Log timing information to the file. Two timing file formats are
   supported now. The classic format is used when only one stream
   (input or output) logging is enabled. The multi-stream format is
   used on --log-io or when --log-in and --log-out are used together.
   See also --logging-format.

One of these paragraphs should give a solution that avoids needing 2>.

Re: Does "LC_ALL=C" work on all shells?

[Franco Martelli]

On 14/02/24 at 17:48, Greg Wooledge wrote:

On Wed, Feb 14, 2024 at 05:35:59PM +0100, Franco Martelli wrote:

On 14/02/24 at 17:15, Greg Wooledge wrote:

# env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
~/upgrade-bookwormstep.script

That command is already using Bourne family shell syntax (the 2> part)
so you can drop the env.  It'll fail in csh regardless.  On the other
hand, the env doesn't hurt anything.  It's just extra typing.



Ah! However it's needed for csh users so they are warned, if it's extra
typing it doesn't hurt, thought.


csh cannot redirect stdout and stderr separately.  You can either redirect
stdout only, or redirect them both into the same file.  It has *nothing*
equivalent to >file1 2>file2.


A new question arise spontaneously: how can csh users run a "script" 
saved session using "scriptreplay" command? In the §4.4.1 "Recording the 
session" paragraph ¹  I see this syntax:


# scriptreplay ~/upgrade-bookwormstep.time ~/upgrade-bookwormstep.script

That it uses both stderr and stdout saved separately. Maybe they have to 
use another syntax or forcibly run a Bourne shell as you wrote below:




The usual recommendations for csh users who need to do this are either:

1) Run sh, and then run the command.
2) sh -c 'long command with >file1 2>file2'


Then run env command at the beginning it is useless.

Thanks again

¹ 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#record-session

--
Franco Martelli

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Wed, Feb 14, 2024 at 05:35:59PM +0100, Franco Martelli wrote:
> On 14/02/24 at 17:15, Greg Wooledge wrote:
> > > # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> > > ~/upgrade-bookwormstep.script
> > That command is already using Bourne family shell syntax (the 2> part)
> > so you can drop the env.  It'll fail in csh regardless.  On the other
> > hand, the env doesn't hurt anything.  It's just extra typing.
> > 
> 
> Ah! However it's needed for csh users so they are warned, if it's extra
> typing it doesn't hurt, thought.

csh cannot redirect stdout and stderr separately.  You can either redirect
stdout only, or redirect them both into the same file.  It has *nothing*
equivalent to >file1 2>file2.

The usual recommendations for csh users who need to do this are either:

1) Run sh, and then run the command.
2) sh -c 'long command with >file1 2>file2'

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Wed, Feb 14, 2024 at 05:11:55PM +0100, Franco Martelli wrote:
> Well, I'll go with env command syntax for shells portability. I was asking
> this because I want to suggest a change to the DDP (Debian Documentation
> Project) members for the releases notes documentation ¹
> 
> The change I want to suggest is to add "env LC_ALL=C" to the "script"
> command:
> 
> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> ~/upgrade-bookwormstep.script

That command is already using Bourne family shell syntax (the 2> part)
so you can drop the env.  It'll fail in csh regardless.  On the other
hand, the env doesn't hurt anything.  It's just extra typing.

Re: Does "LC_ALL=C" work on all shells?

[Franco Martelli]

On 13/02/24 at 23:23, Nicolas George wrote:

Will Mengarini (12024-02-13):

* Greg Wooledge  [24-02/13=Tu 15:59 -0500]:

In csh, you need to use env.  Like this:

 


What Greg posted also works, because it's an
invocation of the 'env' command, not csh syntax.


Yes. What made Greg's statement false was not the fact that it does not
work but the verb “need”.


What you posted also works, but it runs the command in a subshell of
csh, so I doubt it gains efficiency over running the command under env.


env is also executed in a subshell, but unlike what I posted, env will
also require an exec() and probably some dynamic linking.



Well, I'll go with env command syntax for shells portability. I was 
asking this because I want to suggest a change to the DDP (Debian 
Documentation Project) members for the releases notes documentation ¹


The change I want to suggest is to add "env LC_ALL=C" to the "script" 
command:


# env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a 
~/upgrade-bookwormstep.script


I think that a recorded session with the output of the commands in 
English is better then a localized session for debugging purposes.


Thanks to all for the feedback!

¹ 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#record-session

--
Franco Martelli

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 22:11, Greg Wooledge wrote:

On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote:

This is from a script installed by a package that does a
dpkg-reconfigure locales to set the locale on the machine.


What package?  What script?


I am working on it with a high rate a speed,  should be completed next year.




BTW where is LANGUAGE defined in the "standards/conventions"?


It's a GNUism.

https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html




--
Hindi madali ang maging ako

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote:
> This is from a script installed by a package that does a
> dpkg-reconfigure locales to set the locale on the machine.

What package?  What script?

> BTW where is LANGUAGE defined in the "standards/conventions"?

It's a GNUism.

https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 21:22, Max Nikulin wrote:

On 14/02/2024 07:56, Gremlin wrote:

Gremlin (12024-02-13):


cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8


Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC 
LC_ALL=$LOC LANGUAGE=$LOC


Do not do it for LANGUAGE, it should obey another conventions

     LANGUAGE=en_US:en

Its value is a list of languages, not a locale. This variable may affect 
messages generated by some applications, especially GUI ones, even when 
LC_ALL is set.







I get your point but I didn't do it, git blame others.

This is from a script installed by a package that does a
dpkg-reconfigure locales to set the locale on the machine.

BTW where is LANGUAGE defined in the "standards/conventions"?

Re: Does "LC_ALL=C" work on all shells?

[Max Nikulin]

On 14/02/2024 07:56, Gremlin wrote:

Gremlin (12024-02-13):


cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8


Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC 
LANGUAGE=$LOC


Do not do it for LANGUAGE, it should obey another conventions

LANGUAGE=en_US:en

Its value is a list of languages, not a locale. This variable may affect 
messages generated by some applications, especially GUI ones, even when 
LC_ALL is set.

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 07:56:46PM -0500, Gremlin wrote:
> Found this in a shell script:
> 
> LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
> LANGUAGE=$LOC

In *what* shell script?

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 19:29, Gremlin wrote:

On 2/13/24 17:48, Nicolas George wrote:

Gremlin (12024-02-13):

Oh like debian does?

cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8


I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?


I will try:

Upon investigation, I can not determine which package
/etc/default/locale belongs too.

dpkg -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale

dpkg-query -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale


apt-file search /etc/default/locale

returns nothing

apt-file search locale|grep '/etc/default'

nothing

cruft-ng doesn't find it

This is going no where fast.




Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC 
LANGUAGE=$LOC

Re: Does "LC_ALL=C" work on all shells?

[Andy Smith]

Hi,

On Tue, Feb 13, 2024 at 07:29:37PM -0500, Gremlin wrote:
> Upon investigation, I can not determine which package
> /etc/default/locale belongs too.

dpkg -S and apt-file will only find files that are actually shipped
in packages. Files that are created or used by maintainer scripts
but not actually shipped by a package will not be found by these
commands.

You can look in all the maintainer scripts to see where it's
mentioned:

$ grep -r /etc/default/locale /var/lib/dpkg/info

which leads me to believe it may be most relevant to the "locales"
package, but this does not enlighten us to how any particular entry
may have been added to that file.

I guess at some point something called update-locale with LC_ALL=C
or something.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 17:48, Nicolas George wrote:

Gremlin (12024-02-13):

Oh like debian does?

cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8


I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?


I will try:

Upon investigation, I can not determine which package
/etc/default/locale belongs too.

dpkg -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale

dpkg-query -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale


apt-file search /etc/default/locale

returns nothing

apt-file search locale|grep '/etc/default'

nothing

cruft-ng doesn't find it

This is going no where fast.

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 11:48:04PM +0100, Nicolas George wrote:
> Gremlin (12024-02-13):
> > Oh like debian does?
> > 
> > cat /etc/default/locale
> > #  File generated by update-locale
> > LANG=en_US.UTF-8
> > LANGUAGE=en_US.UTF-8
> > LC_ALL=en_US.UTF-8
> 
> I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
> you explain how you reached this state?

Indeed.  That is NOT normal.

unicorn:~$ cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Gremlin (12024-02-13):
> Oh like debian does?
> 
> cat /etc/default/locale
> #  File generated by update-locale
> LANG=en_US.UTF-8
> LANGUAGE=en_US.UTF-8
> LC_ALL=en_US.UTF-8

I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 16:45, Greg Wooledge wrote:

On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:

 egrep ALL .bashrc
 LC_ALL=C


This has gone pretty far off the rails, but here we are.  Let's address
this.

DO NOT set LC_ALL in your .bashrc or equivalent files.  This is a horrible
idea.  LC_ALL should only be used in single commands as a full-powered
override, for example when you want to report a bug, and need the output
to be normalized to the "C" locale.


Oh like debian does?

cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8

locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Will Mengarini (12024-02-13):
> * Greg Wooledge  [24-02/13=Tu 15:59 -0500]:
> > In csh, you need to use env.  Like this:


> What Greg posted also works, because it's an
> invocation of the 'env' command, not csh syntax.

Yes. What made Greg's statement false was not the fact that it does not
work but the verb “need”.

> What you posted also works, but it runs the command in a subshell of
> csh, so I doubt it gains efficiency over running the command under env.

env is also executed in a subshell, but unlike what I posted, env will
also require an exec() and probably some dynamic linking.

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[Will Mengarini]

> On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote:
>> ~# LC_ALL=C apt install
>> [... works on ...] all shells other than bash? csh, korn, dash, zsh ...

* Greg Wooledge  [24-02/13=Tu 15:59 -0500]:
> [...] all the Bourne family shells [...]
>
> In csh, you need to use env.  Like this:
>
> % env LC_ALL=C apt install
>
> This works in all shells, at the cost of being slightly less efficient.

* Nicolas George  [24-02/13=Tu 22:04 +0100]:
> No, ( setenv var something ; command ) works with csh.

What Greg posted also works, because it's an
invocation of the 'env' command, not csh syntax.

What you posted also works, but it runs the command in a subshell of
csh, so I doubt it gains efficiency over running the command under env.

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:
> egrep ALL .bashrc
> LC_ALL=C

This has gone pretty far off the rails, but here we are.  Let's address
this.

DO NOT set LC_ALL in your .bashrc or equivalent files.  This is a horrible
idea.  LC_ALL should only be used in single commands as a full-powered
override, for example when you want to report a bug, and need the output
to be normalized to the "C" locale.

In your everyday operations, you should use the LANG variable for the
locale that most closely matches your needs, and individual LC_*
variables (such as LC_TIME) for specific overrides.  Setting it up this
way allows you to override with LC_ALL when needed, *and* it allows you
to fine-tune your preferences.

For example, let's say you wanted the C locale for most things, but
the en_US.utf8 locale for one particular setting (let's say LC_TIME).
You can do this with:

LANG=C LC_TIME=en_US.utf8

but if you try it this way:

LC_ALL=C LC_TIME=en_US.utf8

then it won't work, because LC_ALL overrides everything.  Your LC_TIME
setting will have no effect.

Of course, *none* of this is relevant to the original question, which
was about the shell syntax for overriding environment variables on a
single command.

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

John Conover (12024-02-13):
> > variable LC_ALL to "C" inline of the command e.g.:
   ^
> egrep ALL .bashrc
> LC_ALL=C
> 
> set | egrep ALL
> LC_ALL=C
> 
> dash
> set | egrep ALL

You missed part of the question, what you are showing is not “inline of
the command”.

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[John Conover]

Franco Martelli writes:
> 
> If I want English output of an application I set the environment 
> variable LC_ALL to "C" inline of the command e.g.:
>
.
.
.
> 
> So the question is: does anybody know if this syntax works on all shells 
> other than bash? csh, korn, dash, zsh …
> 

Hi Franco.

egrep ALL .bashrc
LC_ALL=C

set | egrep ALL
LC_ALL=C

dash
set | egrep ALL

So, apparently not, (I don't have it set in /etc/profile, which is
read when dash is invoked; initializing in ~/.profile would work,
too. Probably the same in csh, korn, zsh ...)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Greg Wooledge (12024-02-13):
> This syntax works in all the Bourne family shells, which is all of the
> above *except* csh.
> 
> In csh, you need to use env.

No, ( setenv var something ; command ) works with csh.

>     % env LC_ALL=C apt install
> 
> This works in all shells, at the cost of being slightly less efficient.

And even without a shell.

Regards,

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote:
> ~# LC_ALL=C apt install

> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …

This syntax works in all the Bourne family shells, which is all of the
above *except* csh.

In csh, you need to use env.  Like this:

% env LC_ALL=C apt install

This works in all shells, at the cost of being slightly less efficient.

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Franco Martelli (12024-02-13):
> This is useful when it's needed to submit a bug report or to speak with
> other people in one international mailing list like this :) (apropos sorry
> for my English).

Your English does not look bad. And therefore you would probably be
better making this the default. Translations of software are often
mediocre or worse. (I remember when the French translation of df broke
the alignment of columns.) Use the software in its original version and
you will not have to guess if you misunderstood or if the translator
did.

> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …

apt-get install csh
csh
LC_CTYPE=C ls /doesnotexist
^D
apt-get purge csh

Repeat with other shells. And then tell us what you found out.

Regards,

-- 
  Nicolas George

Does "LC_ALL=C" work on all shells?

[Franco Martelli]

Hi,

If I want English output of an application I set the environment 
variable LC_ALL to "C" inline of the command e.g.:


~# LC_ALL=C apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If I don't set the variable the apt command return output localized:

~# apt install
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

This is useful when it's needed to submit a bug report or to speak with 
other people in one international mailing list like this :) (apropos 
sorry for my English).


So the question is: does anybody know if this syntax works on all shells 
other than bash? csh, korn, dash, zsh …


Thanks in advance, kind regards
--
Franco Martelli

C-Ins vs. C-c [was: xterm PRIMARY and CLIPBOARD selection] Firefox and paste into Terminal with Vim]

[tomas]

On Wed, Feb 07, 2024 at 01:20:19PM +0100, Nicolas George wrote:
> Max Nikulin (12024-02-07):
> > It may be a convention for applications other than terminals, however I am
> > unsure what "standard" means for terminals.
> 
> I have not said it is more “standard for terminals”, I have that it is
> more “standard” fullstop. It is more standard by the virtue of having
> worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X
> tryptich, and still working today in most contexts.

C-c, C-x and C-v is latest documented for the Apple Lisa, around 1983,
although it may have stolen it from the Xerox Alto [0] [1]

C-Ins, S-Del and S-Ins are IBM CUA, around 1987.

So it's the other way around :-)

Cheers

[0] https://en.wikipedia.org/wiki/Apple_Lisa
[1] https://en.wikipedia.org/wiki/Cut%2C_copy%2C_and_paste#Popularization
[2] https://en.wikipedia.org/wiki/IBM_Common_User_Access

-- 
t


signature.asc
Description: PGP signature

Turbo C

[William Torrez Corea]

Can't install correctly the compiler in my computer

Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
> DOSBox version 0.74-3
>

I get the following error when i want compile

   1. *Invalid drive or directory. Press ESC. *
   2. *C:\BIN\BORRAR.C: Unable to create output file
   'C:\TC20\OUTPUT\BORRAR.obj'*

*Attachment the compiler and emulator compressed*

https://www.mediafire.com/file/uq4m5wpwtr3td3k/DosBox_y_TC20.zip/file
-- 

With kindest regards, William.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: /libfreenect/build/wrappers/python/freenect3.c:747:10: fatal error: numpy/arrayobject.h: File or directory not found

[Mario Marietto]

Hello.

I have installed these packages on Debian 11 :

freenect/stable,now 1:0.5.3-2 amd64 [installed]
libfreenect-bin/stable,now 1:0.5.3-2 amd64 [installed, automatic]
libfreenect-demos/stable,now 1:0.5.3-2 amd64 [installed]
libfreenect-dev/stable,now 1:0.5.3-2 amd64 [installed]
libfreenect-doc/stable,stable,now 1:0.5.3-2 all [installed, automatic]
libfreenect0.5/stable,now 1:0.5.3-2 amd64 [installed, automatic]

What I really like to do is to choose the kinect xbox 360 as a mic. I find
it very comfortable to talk without having a mic in my mouth. I can use it
to send voice messages to my whatsapp and Telegram friends. I've already
done the same with the kinect 2 that I have attached to my Jetson nano and
it worked. But on the Jetson Nano I have installed Ubuntu 20.04. So,I would
like to know...what's still missing on Debian,after having installed the
packages that you see above ? Because I don't see any Xbox NUI Sensor
Analog Surround 4.0 on the XFCE pulseaudio addon (instead,it is present on
Ubuntu 20.04). Thanks.

On Sun, Apr 2, 2023 at 1:18 AM Kushal Kumaran  wrote:

> On Sat, Apr 01 2023 at 10:42:11 PM, Mario Marietto 
> wrote:
> > Hello.
> >
> > I'm trying to compile libfreenect because I want to use my kinect xbox
> 360
> > on Debian 11. I'm following the tutorial that I've found here :
> >
>
> libfreenect is already packaged in debian.  Is there a reason you're
> building from source?  It seems like quite a complex package to build.
> If you must, consider taking a look at the existing debian packaging for
> hints.
>
> > snipped numpy/cython errors
>
> --
> regards,
> kushal
>
>

-- 
Mario.

Re: /libfreenect/build/wrappers/python/freenect3.c:747:10: fatal error: numpy/arrayobject.h: File or directory not found

[Kushal Kumaran]

On Sat, Apr 01 2023 at 10:42:11 PM, Mario Marietto  
wrote:
> Hello.
>
> I'm trying to compile libfreenect because I want to use my kinect xbox 360
> on Debian 11. I'm following the tutorial that I've found here :
>

libfreenect is already packaged in debian.  Is there a reason you're
building from source?  It seems like quite a complex package to build.
If you must, consider taking a look at the existing debian packaging for
hints.

> snipped numpy/cython errors

-- 
regards,
kushal

/libfreenect/build/wrappers/python/freenect3.c:747:10: fatal error: numpy/arrayobject.h: File or directory not found

[Mario Marietto]

Hello.

I'm trying to compile libfreenect because I want to use my kinect xbox 360
on Debian 11. I'm following the tutorial that I've found here :

https://github.com/OpenKinect/libfreenect

here :

https://itsourcecode.com/modulenotfounderror/no-module-named-numpy-core-_multiarray_umath-solved/

here :

https://github.com/lava/matplotlib-cpp/issues/46

this is what I did :


# python3 --versionPython 3.8.10# /usr/bin/python3 --versionPython
3.8.10marietto@marietto:/mnt/zroot2/zroot2/libfreenect/build# sudo
cmake .. -L -DBUILD_PYTHON3=ON -DPython3_EXACTVERSION=3.8.10
-DCYTHON_EXECUTABLE=/usr/bin/cython3 -DBUILD_REDIST_PACKAGE=OFF
-DPYTHON_INCLUDE_DIR=/usr/local/lib/python3.8/dist-packages/numpy/core/include--
Operating system is Linux-- Got System Processor x86_64-- Linux x86_64
Detected-- libfreenect will be installed to /usr/local-- Headers will
be installed to /usr/local/include/libfreenect-- Libraries will be
installed to /usr/local/lib-- Found libusb-1.0:--  - Includes:
/usr/include/libusb-1.0--  - Libraries:
/usr/lib/x86_64-linux-gnu/libusb-1.0.soTraceback (most recent call
last):  File "/usr/local/lib/python3.8/numpy/core/__init__.py", line
23, in from . import multiarray  File
"/usr/local/lib/python3.8/numpy/core/multiarray.py", line 10, in
from . import overrides  File
"/usr/local/lib/python3.8/numpy/core/overrides.py", line 6, in
from numpy.core._multiarray_umath import
(ModuleNotFoundError: No module named
'numpy.core._multiarray_umath'During handling of the above exception,
another exception occurred:Traceback (most recent call last):  File
"", line 1, in   File
"/usr/local/lib/python3.8/numpy/__init__.py", line 141, in 
from . import core  File
"/usr/local/lib/python3.8/numpy/core/__init__.py", line 49, in
raise ImportError(msg)ImportError: IMPORTANT: PLEASE READ
THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!Importing the numpy
C-extensions failed. This error can happen formany reasons, often due
to issues with your setup or how NumPy wasinstalled.We have compiled
some common reasons and troubleshooting tips at:
https://numpy.org/devdocs/user/troubleshooting-importerror.htmlPlease
note and check the following:  * The Python version is: Python3.8 from
"/usr/local/bin/python3.8"  * The NumPy version is: "1.24.2"and make
sure that they are the versions you expect.Please carefully study the
documentation linked above for further help.Original error was: No
module named 'numpy.core._multiarray_umath'-- Configuring done
(0.6s)-- Generating done (0.0s)CMake Warning:  Manually-specified
variables were not used by the project:PYTHON_INCLUDE_DIR--
Build files have been written to:
/mnt/zroot2/zroot2/libfreenect/build-- Cache
valuesBUILD_AS3_SERVER:BOOL=OFFBUILD_CPACK_DEB:BOOL=OFFBUILD_CPACK_RPM:BOOL=OFFBUILD_CPACK_TGZ:BOOL=OFFBUILD_CPP:BOOL=ONBUILD_CV:BOOL=OFFBUILD_C_SYNC:BOOL=ONBUILD_EXAMPLES:BOOL=ONBUILD_FAKENECT:BOOL=ONBUILD_OPENNI2_DRIVER:BOOL=OFFBUILD_PYTHON:BOOL=OFFBUILD_PYTHON2:BOOL=OFFBUILD_PYTHON3:BOOL=ONBUILD_REDIST_PACKAGE:BOOL=OFFCMAKE_BUILD_TYPE:STRING=CMAKE_INSTALL_PREFIX:PATH=/usr/localCYTHON_EXECUTABLE:FILEPATH=/usr/bin/cython3LIBUSB_1_INCLUDE_DIR:PATH=/usr/include/libusb-1.0LIBUSB_1_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libusb-1.0.soPython2_EXACTVERSION:STRING=Python3_EXACTVERSION:STRING=3.8.10marietto@marietto:/mnt/zroot2/zroot2/libfreenect/build#
sudo makeAlready have audios.bin[  0%] Built target firmware[ 16%]
Built target freenect[ 32%] Built target freenectstatic[ 35%] Built
target freenect-camtest[ 39%] Built target freenect-wavrecord[ 42%]
Built target freenect-glview[ 46%] Built target freenect-regview[ 50%]
Built target freenect-hiview[ 53%] Built target freenect-chunkview[
57%] Built target freenect-micview[ 60%] Built target freenect_sync[
64%] Built target freenect-regtest[ 67%] Built target
freenect-tiltdemo[ 71%] Built target freenect-glpclview[ 78%] Built
target fakenect[ 83%] Built target fakenect-record[ 87%] Built target
freenect_sync_static[ 91%] Built target freenect-cppview[ 94%] Built
target freenect-cpp_pcview[ 96%] Building C object
wrappers/python/CMakeFiles/cython3_freenect.dir/freenect3.c.o/mnt/zroot2/zroot2/libfreenect/build/wrappers/python/freenect3.c:747:10:
fatal error: numpy/arrayobject.h: File o directory non esistente  747
| #include "numpy/arrayobject.h"  |
^compilation terminated.make[2]: ***
[wrappers/python/CMakeFiles/cython3_freenect.dir/build.make:80:
wrappers/python/CMakeFiles/cython3_freenect.dir/freenect3.c.o] Errore
1make[1]: *** [CMakeFiles/Makefile2:741:
wrappers/python/CMakeFiles/cython3_freenect.dir/all] Errore 2make: ***
[Makefile:136: all] Errore 2

-- 
Mario.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Fri 03 Feb 2023 at 23:59:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> > I don't know a lot about zsh, but I ran it, typed some letters, and
> > pressed Ctrl-U, and they were all erased as expected.
> 
> But the point is multiline, as you did then:
> 
> > One difference that I did notice in zsh is that its handling of Ctrl-U
> > after a bracketed paste is different from bash's.  I used "seq 3 | xclip -i"
> > to load three harmless lines into the paste selection, and then pasted
> > it into zsh, and into bash, and pressed Ctrl-U in each of them.  In the
> > zsh case, only the third line was erased, and the first 2 were still
> > there, and were executed when I pressed Enter.  In bash, all 3 lines
> > were erased, and Enter didn't execute any of them.
> > 
> > Whether that's a bug in zsh, I can't say.
> 
> I would say that's expected and this is actually a bug in bash:
> "kill-whole-line" means to kill the line, not the whole text.

But the whole text /behaves/ as one line containing embedded newlines,
which you will quickly realise if you ever try to edit it before
pressing Enter. If you want to edit something that's apparently
"three lines up", you can't press ↑ to move up three lines:
you have to hold down the ← key and wait until it reaches said
position. And you can add and remove the embedded newlines at will.

When you press Enter, a "transformation" takes place, and the paste
is interpreted in the context in which it finds itself, which can
lead to surprises.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> > About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> > not really usable in zsh to erase long pastes (unless one changes
> > the default bindings). But Ctrl-C is fine in zsh.
> 
> Ctrl-U is bound to "kill" at the terminal level (e.g. stty(1)).  It's
> more than just a shell feature.  You can use it in any setting where
> a terminal is in "canonical mode", e.g. "cat" with no arguments reading
> from a terminal, or a terminal's login prompt.

Shells do not use "canonical mode". In zsh, Ctrl-U is handled by zle,
bash uses readline, AFAIK, so that it depends on the Ctrl-U binding.
See examples in the readline(3readline) man page.

> I don't know a lot about zsh, but I ran it, typed some letters, and
> pressed Ctrl-U, and they were all erased as expected.

But the point is multiline, as you did then:

> One difference that I did notice in zsh is that its handling of Ctrl-U
> after a bracketed paste is different from bash's.  I used "seq 3 | xclip -i"
> to load three harmless lines into the paste selection, and then pasted
> it into zsh, and into bash, and pressed Ctrl-U in each of them.  In the
> zsh case, only the third line was erased, and the first 2 were still
> there, and were executed when I pressed Enter.  In bash, all 3 lines
> were erased, and Enter didn't execute any of them.
> 
> Whether that's a bug in zsh, I can't say.

I would say that's expected and this is actually a bug in bash:
"kill-whole-line" means to kill the line, not the whole text.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Thu 26 Jan 2023 at 18:34:24 (+0100), Vincent Lefevre wrote:
> On 2023-01-25 14:08:07 -0600, David Wright wrote:
> > On Tue 24 Jan 2023 at 18:29:38 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-24 10:36:05 -0600, David Wright wrote:
> > > > On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> > > [...]
> > > > > For instance, if I paste the following 3 lines
> > > > > 
> > > > > foo1
> > > > > foo2
> > > > > foo3
> > > > > 
> > > > > in dash, I get:
> > > > > 
> > > > > $ foo1
> > > > > foo2
> > > > > foo3
> > > > > sh: 1: foo1: not found
> > > > > $ sh: 2: foo2: not found
> > > > > $ sh: 3: foo3: not found
> > > > > $ 
> > > > > 
> > > > > Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> > > > > and the 3 commands have already been executed.
> > > > 
> > > > Well, sure, you've pasted lines into a shell, and they get executed.
> > > > I don't think you want to prevent that.
> > > 
> > > With bracketed paste, the lines remains in the command line at the
> > > prompt until the user has typed the [Enter] key to run them. So the
> > > user can also type Ctrl-C to prevent any execution (or he can edit
> > > the command).
> > 
> > You're preaching to the converted; see
> > https://lists.debian.org/debian-user/2023/01/msg00562.html
> > two posts back.
> 
> About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> not really usable in zsh to erase long pastes (unless one changes
> the default bindings). But Ctrl-C is fine in zsh.

So it's just a case of choosing the appropriate workaround for
your release/terminal/shell. (I suppose I should add: in whatever
combination.) Will wayland matter? :)

> > My comment was with respect to your point 2, which was about
> > non-bracketed paste, and which was snipped off the top of your post.
> > 
> > BTW are you implying that dash does bracketed paste? I didn't know that.
> 
> No, the opposite: I'm showing above that dash does not support
> bracketed paste. This means that running an X application in
> background with "&" would not solve the problem with dash, and this
> would actually be worse with short pastes (which are cancellable
> with Ctrl-C or Ctrl-Z when an application is running in foreground).
> I normally don't run X application from dash (which I use mainly for
> testing shell behavior), but this doesn't mean that this will never
> occur.

Ditto as above. Sorry & doesn't work for you. I guess there's
a point at which you run out of options for the computer to
"automatically" work around the effects of your actions, and you
just have to put up with negative consequences of your mistakes.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Greg Wooledge]

On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> not really usable in zsh to erase long pastes (unless one changes
> the default bindings). But Ctrl-C is fine in zsh.

Ctrl-U is bound to "kill" at the terminal level (e.g. stty(1)).  It's
more than just a shell feature.  You can use it in any setting where
a terminal is in "canonical mode", e.g. "cat" with no arguments reading
from a terminal, or a terminal's login prompt.

I don't know a lot about zsh, but I ran it, typed some letters, and
pressed Ctrl-U, and they were all erased as expected.

One difference that I did notice in zsh is that its handling of Ctrl-U
after a bracketed paste is different from bash's.  I used "seq 3 | xclip -i"
to load three harmless lines into the paste selection, and then pasted
it into zsh, and into bash, and pressed Ctrl-U in each of them.  In the
zsh case, only the third line was erased, and the first 2 were still
there, and were executed when I pressed Enter.  In bash, all 3 lines
were erased, and Enter didn't execute any of them.

Whether that's a bug in zsh, I can't say.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Curt]

On 2023-01-24, Vincent Lefevre  wrote:
>
>> In terms of accidents, you've just driven a car at a brick wall,
>> and it runs into it, as expected.
>
> No, with modern shells, bracketed paste is precisely there to avoid
> such kind of issues.
>

I thought it was designed to avoid formatting problems when pasting code
into a text editor.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-25 14:08:07 -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 18:29:38 (+0100), Vincent Lefevre wrote:
> > On 2023-01-24 10:36:05 -0600, David Wright wrote:
> > > On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> > [...]
> > > > For instance, if I paste the following 3 lines
> > > > 
> > > > foo1
> > > > foo2
> > > > foo3
> > > > 
> > > > in dash, I get:
> > > > 
> > > > $ foo1
> > > > foo2
> > > > foo3
> > > > sh: 1: foo1: not found
> > > > $ sh: 2: foo2: not found
> > > > $ sh: 3: foo3: not found
> > > > $ 
> > > > 
> > > > Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> > > > and the 3 commands have already been executed.
> > > 
> > > Well, sure, you've pasted lines into a shell, and they get executed.
> > > I don't think you want to prevent that.
> > 
> > With bracketed paste, the lines remains in the command line at the
> > prompt until the user has typed the [Enter] key to run them. So the
> > user can also type Ctrl-C to prevent any execution (or he can edit
> > the command).
> 
> You're preaching to the converted; see
> https://lists.debian.org/debian-user/2023/01/msg00562.html
> two posts back.

About this, Ctrl-U is just a shell feature. Contrary to bash, it is
not really usable in zsh to erase long pastes (unless one changes
the default bindings). But Ctrl-C is fine in zsh.

> My comment was with respect to your point 2, which was about
> non-bracketed paste, and which was snipped off the top of your post.
> 
> BTW are you implying that dash does bracketed paste? I didn't know that.

No, the opposite: I'm showing above that dash does not support
bracketed paste. This means that running an X application in
background with "&" would not solve the problem with dash, and this
would actually be worse with short pastes (which are cancellable
with Ctrl-C or Ctrl-Z when an application is running in foreground).
I normally don't run X application from dash (which I use mainly for
testing shell behavior), but this doesn't mean that this will never
occur.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Tue 24 Jan 2023 at 18:29:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-24 10:36:05 -0600, David Wright wrote:
> > On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> [...]
> > > For instance, if I paste the following 3 lines
> > > 
> > > foo1
> > > foo2
> > > foo3
> > > 
> > > in dash, I get:
> > > 
> > > $ foo1
> > > foo2
> > > foo3
> > > sh: 1: foo1: not found
> > > $ sh: 2: foo2: not found
> > > $ sh: 3: foo3: not found
> > > $ 
> > > 
> > > Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> > > and the 3 commands have already been executed.
> > 
> > Well, sure, you've pasted lines into a shell, and they get executed.
> > I don't think you want to prevent that.
> 
> With bracketed paste, the lines remains in the command line at the
> prompt until the user has typed the [Enter] key to run them. So the
> user can also type Ctrl-C to prevent any execution (or he can edit
> the command).

You're preaching to the converted; see
https://lists.debian.org/debian-user/2023/01/msg00562.html
two posts back.

My comment was with respect to your point 2, which was about
non-bracketed paste, and which was snipped off the top of your post.

BTW are you implying that dash does bracketed paste? I didn't know that.

> For instance, in zsh:
> 
> cventin:~> foo1
> foo2
> foo3
> 
> If I type [Enter], I get:
> 
> zsh: command not found: foo1
> zsh: command not found: foo2
> zsh: command not found: foo3
> cventin:~[127]>
> 
> But instead of [Enter], if I type Ctrl-C, I just get:
> 
> cventin:~[1!]>
> 
> Nothing has been executed. (The exit code 1 is strange and may be
> caused by a bug in some hook. This occurs only if I do a Ctrl-C
> directly after a paste, otherwise I get 130 as expected.)
> 
> > In terms of accidents, you've just driven a car at a brick wall,
> > and it runs into it, as expected.
> 
> No, with modern shells, bracketed paste is precisely there to avoid
> such kind of issues.

Quite clever, that. You quote my comment after some anecdote of yours
that gives it the opposite context, so you can then disgree with it.

BTW I don't know anything about nooks and zsh. As I said at the end
of my previous post, I'm not really interested in

> > testing the gamut of releases, terminals and shells.

But if you are, then it might be worth your posting a summary of your
findings in the form of a table that others could understand, rather
than in a back and forth of over-snipped posts.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-24 10:36:05 -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
[...]
> > For instance, if I paste the following 3 lines
> > 
> > foo1
> > foo2
> > foo3
> > 
> > in dash, I get:
> > 
> > $ foo1
> > foo2
> > foo3
> > sh: 1: foo1: not found
> > $ sh: 2: foo2: not found
> > $ sh: 3: foo3: not found
> > $ 
> > 
> > Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> > and the 3 commands have already been executed.
> 
> Well, sure, you've pasted lines into a shell, and they get executed.
> I don't think you want to prevent that.

With bracketed paste, the lines remains in the command line at the
prompt until the user has typed the [Enter] key to run them. So the
user can also type Ctrl-C to prevent any execution (or he can edit
the command).

For instance, in zsh:

cventin:~> foo1
foo2
foo3

If I type [Enter], I get:

zsh: command not found: foo1
zsh: command not found: foo2
zsh: command not found: foo3
cventin:~[127]>

But instead of [Enter], if I type Ctrl-C, I just get:

cventin:~[1!]>

Nothing has been executed. (The exit code 1 is strange and may be
caused by a bug in some hook. This occurs only if I do a Ctrl-C
directly after a paste, otherwise I get 130 as expected.)

> In terms of accidents, you've just driven a car at a brick wall,
> and it runs into it, as expected.

No, with modern shells, bracketed paste is precisely there to avoid
such kind of issues.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[tomas]

On Tue, Jan 24, 2023 at 10:34:01AM -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > > input from that point forward.
> > 
> > They are actually not ignored, but delayed by the terminal emulator.
> > This is an issue because Ctrl-C (the intr character) is normally
> > taken into account immediately (with a SIGINT generation), even if
> > earlier characters have not been read yet by the command.
> > 
> > And this is apparently the same for the other special characters
> > as defined by stty.
> 
> How did you determine that they're actually received by the terminal
> emulator after the buffer is full? IOW where are they being stored?

Actually, AFAIK, its not the terminal emulator, but the PTY which does
that translation. So your argument would be valid if there's something
/before/ the PTY doing the buffering.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-24 10:34:01 -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > > input from that point forward.
> > 
> > They are actually not ignored, but delayed by the terminal emulator.
> > This is an issue because Ctrl-C (the intr character) is normally
> > taken into account immediately (with a SIGINT generation), even if
> > earlier characters have not been read yet by the command.
> > 
> > And this is apparently the same for the other special characters
> > as defined by stty.
> 
> How did you determine that they're actually received by the terminal
> emulator after the buffer is full? IOW where are they being stored?

I don't know where they are stored (this is probably part of the
terminal code), but

1. Create file1 with
printf "%d\n" `seq ` > file1
2. Select the contents of file1.
3. In a terminal (xterm in my case), type "some_app ; cat > file2",
   where some_app is an X application or "sleep 10", for instance.
4. Paste with the middle button in the terminal.
5. Type Ctrl-C in the terminal.
6. Quit some_app (or let it end, e.g. in case of sleep).

I get something like:

[...]
9982
9983
9984
9985
9986
9987
99^C

in the terminal, and file2 ends with "9987" due to the Ctrl-C.

Another try:

[...]
9979
9980
9981
9982
9983
9984
99^C

and this time, the file ends with "9912". This is not surprising
as the characters probably appear in the terminal before they are
processed by "cat". Since the writes to the pty by xterm and the
process by "cat" are concurrent, one doesn't exactly obtain the
same result at each test. But in every case, the Ctrl-C is taken
into account only near the end.

And a test with GNOME Terminal:

[...]
9996
9997
9998

^C

and the file ends with "9181".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 23:27:11 -0600, David Wright wrote:
> > On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-21 23:04:30 -0600, David Wright wrote:
> > > 
> > > > In this case, if I paste the large file, I do see almost the start
> > > > of the file (I seem to lose just the first line, which rolls off the
> > > > top), and ^C still works, returning to the prompt with return code
> > > > 130.
> > > > 
> > > > (I don't know whether all terminals behave like this: I just use
> > > > xterm myself.)
> > > 
> > > This should work if the terminal and the shell both support
> > > bracketed paste.
> > 
> > Bracketed paste allows me to erase all the input with ^U.
> > But I didn't think you needed bracketed paste for ^C to work.
> 
> This is not what I meant. The context was the following one:
> 
> | The only suggestion I can give is that you start the applications
> | concerned with &, so that you get the xterm prompt back.
> 
> So, if there is a prompt, the shell will get the large paste
> (possibly with some loss of data due to the pty bug), and there
> will be no issues with Ctrl-C itself because the shell will have
> read all the input data.

As I say, I haven't observed bug #273194 myself, while doing my
best to provoke it.

> However, before the user can type Ctrl-C, the shell will interpret
> the characters from the large paste immediately. There are 2 cases:
> 
> 1. If bracketed paste is supported, then all the characters will just
> be interpreted as quoted characters, like if Ctrl-V were typed before
> each character. In particular, a newline character will not validate
> the command, but will be inserted in the command itself (where it can
> appear either as a line break if the shell supports multiline editing,
> or as ^J).
> 
> 2. If bracketed paste is not supported, then a newline character will
> validate the command (except if it happens to be in quoted text). So
> one will get lots of buggy commands run by the shell, which is the
> same issue as the ignored Ctrl-C without the prompt.
> 
> For instance, if I paste the following 3 lines
> 
> foo1
> foo2
> foo3
> 
> in dash, I get:
> 
> $ foo1
> foo2
> foo3
> sh: 1: foo1: not found
> $ sh: 2: foo2: not found
> $ sh: 3: foo3: not found
> $ 
> 
> Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> and the 3 commands have already been executed.

Well, sure, you've pasted lines into a shell, and they get executed.
I don't think you want to prevent that.

In terms of accidents, you've just driven a car at a brick wall,
and it runs into it, as expected.

But my context for using & was bullseye, xterm and bash, not
testing the gamut of releases, terminals and shells.
AIUI bracketed paste is now the default since bullseye, and
if you turn it off, you have to carry the risks: accidental
pasting is one of the most obvious.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Tue 24 Jan 2023 at 16:17:32 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 23:27:27 -0600, David Wright wrote:
> > On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > > > This might be a limitation of Linux's pty(7) subsystem.  The xterm
> > > > manpage mentions the following:
> > > > 
> > > > ,
> > > > | BUGS
> > > > |  Large pastes do not work on some systems.  This is not a bug in
> > > > |  xterm; it is a bug in the pseudo terminal driver of those 
> > > > systems.
> > > > |  Xterm feeds large pastes to the pty only as fast as the pty will
> > > > |  accept data, but some pty drivers do not return enough 
> > > > information
> > > > |  to know if the write has succeeded.
> > > > `
> > > > 
> > > > See also https://bugs.debian.org/273194 in xterm.  Disclaimer: I do not
> > > > have any expertise in that area.
> > > 
> > > Thanks. Since several terminals are affected (I've tested xterm,
> > > mlterm and GNOME Terminal), with exactly the same behavior, each
> > > after 4095 characters, this is probably this bug.
> > 
> > I'm unconvinced. The bug was exhibited when the paste was into an
> > xterm running cat > /dev/null which should accept any amount of
> > input. I've catted 275KB to a real file, and got a perfect copy
> > every time.
> 
> Indeed, this works fine with xterm and GNOME Terminal, even with
> "xterm; cat > foo" and the paste done before quitting the xterm
> (or whatever command that will not terminate immediately). But
> mlterm has some problems with that.
> 
> I suppose that the terminal can detect when the pty will no longer
> accept additional characters. And the paste resumes as soon as
> input is read by "cat".
> 
> With xterm, if I do the large paste with middle-click and type
> abcdef, then the end of the paste is missing, probably
> because the Ctrl-C occurred during the last write to the pty.

AFAIK whenever you interrupt a process with ^C, you're going to
have a problem with knowing exactly how much of the processing was
completed, and what sort of "tidying up/throwing away" was done.

The OP talked about posting "a long text". If you relax this to
include binary data, it wouldn't surprise me if surprises occur.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Tue 24 Jan 2023 at 10:03:31 (+), Richmond wrote:
> Greg Wooledge wrote:
> > On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
> >> I didn't test it for the reason I stated. I think it would be better for
> >> OP to test it as he won't do any more damage than he has already done.
> > Here's how you can reproduce the problem without having to worry
> > about execution of the pasted text as commands:
> >
> > 1) Import some text into the paste buffer (xclip -i < somefile).
> > 2) Open an xterm.
> > 3) From the xterm, run "xeyes" or any other X client program, no ampersand.
> > 4) Paste text into the xterm.
> > 5) Try Ctrl keys.  Observe that none of them work.
> > 6) Close the xterm using the window manager controls.
> >
> >> I have come across occasions where ctrl-c doesn't work but ctrl-z does
> >> however.
> > Sure, in a terminal that's in a normal state, that happens all the time,
> > if something is ignoring SIGINT.  The entire point of this thread is
> > that when the input buffer of the pty behind the xterm fills up, none
> > of the signals that are generated by keyboard input in a terminal work
> > any longer.  The only resort is to close the xterm.
> >
> No that wasn't the entire point of the thread. The OP didn't know the
> cause, it was presumed by David Wright that it was caused by the buffer
> filling up. But it could have been caused by some spurious character in
> the file, e.g. ctrl-s.

In that case, AFAICT, ^C still works, as the buffer's not full
(assuming it occurs early enough in the input), but it can kill
the foreground application too. ^Q also performs its normal function,
but that just reverts to the undesirable outcome of filling up
the buffer. And, of course, you've expanded the original problem
to one of pasting binary data.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > input from that point forward.
> 
> They are actually not ignored, but delayed by the terminal emulator.
> This is an issue because Ctrl-C (the intr character) is normally
> taken into account immediately (with a SIGINT generation), even if
> earlier characters have not been read yet by the command.
> 
> And this is apparently the same for the other special characters
> as defined by stty.

How did you determine that they're actually received by the terminal
emulator after the buffer is full? IOW where are they being stored?

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-24 10:03:31 +, Richmond wrote:
> No that wasn't the entire point of the thread. The OP didn't know the
> cause, it was presumed by David Wright that it was caused by the buffer
> filling up. But it could have been caused by some spurious character in
> the file, e.g. ctrl-s.

I know that in general, the file does not contain special characters
for the terminal. BTW, Ctrl-S does not prevent Ctrl-C from working:

cventin% sleep 999
abc^Sde^C
cventin% 

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.

They are actually not ignored, but delayed by the terminal emulator.
This is an issue because Ctrl-C (the intr character) is normally
taken into account immediately (with a SIGINT generation), even if
earlier characters have not been read yet by the command.

And this is apparently the same for the other special characters
as defined by stty.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-22 23:27:27 -0600, David Wright wrote:
> On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > > This might be a limitation of Linux's pty(7) subsystem.  The xterm
> > > manpage mentions the following:
> > > 
> > > ,
> > > | BUGS
> > > |  Large pastes do not work on some systems.  This is not a bug in
> > > |  xterm; it is a bug in the pseudo terminal driver of those systems.
> > > |  Xterm feeds large pastes to the pty only as fast as the pty will
> > > |  accept data, but some pty drivers do not return enough information
> > > |  to know if the write has succeeded.
> > > `
> > > 
> > > See also https://bugs.debian.org/273194 in xterm.  Disclaimer: I do not
> > > have any expertise in that area.
> > 
> > Thanks. Since several terminals are affected (I've tested xterm,
> > mlterm and GNOME Terminal), with exactly the same behavior, each
> > after 4095 characters, this is probably this bug.
> 
> I'm unconvinced. The bug was exhibited when the paste was into an
> xterm running cat > /dev/null which should accept any amount of
> input. I've catted 275KB to a real file, and got a perfect copy
> every time.

Indeed, this works fine with xterm and GNOME Terminal, even with
"xterm; cat > foo" and the paste done before quitting the xterm
(or whatever command that will not terminate immediately). But
mlterm has some problems with that.

I suppose that the terminal can detect when the pty will no longer
accept additional characters. And the paste resumes as soon as
input is read by "cat".

With xterm, if I do the large paste with middle-click and type
abcdef, then the end of the paste is missing, probably
because the Ctrl-C occurred during the last write to the pty.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-22 23:27:11 -0600, David Wright wrote:
> On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> > On 2023-01-21 23:04:30 -0600, David Wright wrote:
> > 
> > > In this case, if I paste the large file, I do see almost the start
> > > of the file (I seem to lose just the first line, which rolls off the
> > > top), and ^C still works, returning to the prompt with return code
> > > 130.
> > > 
> > > (I don't know whether all terminals behave like this: I just use
> > > xterm myself.)
> > 
> > This should work if the terminal and the shell both support
> > bracketed paste.
> 
> Bracketed paste allows me to erase all the input with ^U.
> But I didn't think you needed bracketed paste for ^C to work.

This is not what I meant. The context was the following one:

| The only suggestion I can give is that you start the applications
| concerned with &, so that you get the xterm prompt back.

So, if there is a prompt, the shell will get the large paste
(possibly with some loss of data due to the pty bug), and there
will be no issues with Ctrl-C itself because the shell will have
read all the input data.

However, before the user can type Ctrl-C, the shell will interpret
the characters from the large paste immediately. There are 2 cases:

1. If bracketed paste is supported, then all the characters will just
be interpreted as quoted characters, like if Ctrl-V were typed before
each character. In particular, a newline character will not validate
the command, but will be inserted in the command itself (where it can
appear either as a line break if the shell supports multiline editing,
or as ^J).

2. If bracketed paste is not supported, then a newline character will
validate the command (except if it happens to be in quoted text). So
one will get lots of buggy commands run by the shell, which is the
same issue as the ignored Ctrl-C without the prompt.

For instance, if I paste the following 3 lines

foo1
foo2
foo3

in dash, I get:

$ foo1
foo2
foo3
sh: 1: foo1: not found
$ sh: 2: foo2: not found
$ sh: 3: foo3: not found
$ 

Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
and the 3 commands have already been executed.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Richmond]

Greg Wooledge wrote:
> On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
>> I didn't test it for the reason I stated. I think it would be better for
>> OP to test it as he won't do any more damage than he has already done.
> Here's how you can reproduce the problem without having to worry
> about execution of the pasted text as commands:
>
> 1) Import some text into the paste buffer (xclip -i < somefile).
> 2) Open an xterm.
> 3) From the xterm, run "xeyes" or any other X client program, no ampersand.
> 4) Paste text into the xterm.
> 5) Try Ctrl keys.  Observe that none of them work.
> 6) Close the xterm using the window manager controls.
>
>> I have come across occasions where ctrl-c doesn't work but ctrl-z does
>> however.
> Sure, in a terminal that's in a normal state, that happens all the time,
> if something is ignoring SIGINT.  The entire point of this thread is
> that when the input buffer of the pty behind the xterm fills up, none
> of the signals that are generated by keyboard input in a terminal work
> any longer.  The only resort is to close the xterm.
>
No that wasn't the entire point of the thread. The OP didn't know the
cause, it was presumed by David Wright that it was caused by the buffer
filling up. But it could have been caused by some spurious character in
the file, e.g. ctrl-s.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Greg Wooledge]

On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
> I didn't test it for the reason I stated. I think it would be better for
> OP to test it as he won't do any more damage than he has already done.

Here's how you can reproduce the problem without having to worry
about execution of the pasted text as commands:

1) Import some text into the paste buffer (xclip -i < somefile).
2) Open an xterm.
3) From the xterm, run "xeyes" or any other X client program, no ampersand.
4) Paste text into the xterm.
5) Try Ctrl keys.  Observe that none of them work.
6) Close the xterm using the window manager controls.

> I have come across occasions where ctrl-c doesn't work but ctrl-z does
> however.

Sure, in a terminal that's in a normal state, that happens all the time,
if something is ignoring SIGINT.  The entire point of this thread is
that when the input buffer of the pty behind the xterm fills up, none
of the signals that are generated by keyboard input in a terminal work
any longer.  The only resort is to close the xterm.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[tomas]

On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote:
> Greg Wooledge  writes:
> 
> > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > input from that point forward.

[...]

> I have come across occasions where ctrl-c doesn't work but ctrl-z does
> however.

This is most probably for a totally different reason that the
one which seems at work here.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Richmond]

Greg Wooledge  writes:

> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.
>
> (Are people not actually *testing* these things before proposing them?)

I didn't test it for the reason I stated. I think it would be better for
OP to test it as he won't do any more damage than he has already done.

I have come across occasions where ctrl-c doesn't work but ctrl-z does
however.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > This might be a limitation of Linux's pty(7) subsystem.  The xterm
> > manpage mentions the following:
> > 
> > ,
> > | BUGS
> > |  Large pastes do not work on some systems.  This is not a bug in
> > |  xterm; it is a bug in the pseudo terminal driver of those systems.
> > |  Xterm feeds large pastes to the pty only as fast as the pty will
> > |  accept data, but some pty drivers do not return enough information
> > |  to know if the write has succeeded.
> > `
> > 
> > See also https://bugs.debian.org/273194 in xterm.  Disclaimer: I do not
> > have any expertise in that area.
> 
> Thanks. Since several terminals are affected (I've tested xterm,
> mlterm and GNOME Terminal), with exactly the same behavior, each
> after 4095 characters, this is probably this bug.

I'm unconvinced. The bug was exhibited when the paste was into an
xterm running cat > /dev/null which should accept any amount of
input. I've catted 275KB to a real file, and got a perfect copy
every time.

In order to clarify what I see when I paste into the actual bash
prompt in an xterm, I edited the 275KB file to put all the text
on one line. When I pasted this version into the xterm, I see
the last section of the file, right up to the last character,
filling the window. As I have bracketed paste, all the text is
highlighted, and I can clear the input with ^U (because it's
bracketed), leaving a blank screen, or cancel it with ^C, which
leaves the detritus unhighlighted.

The 4KB limitation only kicks in when I paste into an xterm
while it is "otherwise engaged", ie it's running a windowed
application, and so the xterm is not accepting input in the
normal way, but presumably stuffing it into some sort of
4KB-sized buffer that bash acts upon only when the windowed
application quits.

The only post in bug #273194 that mentions this circumstance
is your own at message #40.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-21 23:04:30 -0600, David Wright wrote:
> 
> > In this case, if I paste the large file, I do see almost the start
> > of the file (I seem to lose just the first line, which rolls off the
> > top), and ^C still works, returning to the prompt with return code
> > 130.
> > 
> > (I don't know whether all terminals behave like this: I just use
> > xterm myself.)
> 
> This should work if the terminal and the shell both support
> bracketed paste.

Bracketed paste allows me to erase all the input with ^U.
But I didn't think you needed bracketed paste for ^C to work.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Sun 22 Jan 2023 at 15:35:08 (-0500), Greg Wooledge wrote:
> On Sun, Jan 22, 2023 at 07:54:39PM +, Richmond wrote:
> > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > But nothing happens.
> > You could try pressing ctrl-z at this point to send the application into
> > background.
> 
> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.
> 
> (Are people not actually *testing* these things before proposing them?)

Well /I/ certainly do. The only thing that surprises me is that in all
the years I've been pasting into an emacs window that's partly
overlaying its xterm parent, I've never accidentally pasted into
the xterm anything big enough to provoke this problem.

I tried pasting largeish text files (275KB) into both emacs
and xterm (the latter using cat >filename) and have had no
problems. I generated the copies in two ways, either ^A^C
in Firefox when displaying the original file, or with
xclip original-file, and pasted them with Sh-Insert.

All the pasted copies were identical with the original, so
I didn't hit bug #273194 mentioned by Sven.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-21 23:04:30 -0600, David Wright wrote:
> The only suggestion I can give is that you start the applications
> concerned with &, so that you get the xterm prompt back.

Perhaps. For Emacs, this is more complex because it can also
run in the terminal, and the ultimate solution could be to
write a shell function to run Emacs with "&" only when DISPLAY
is set and the -nw option is not used.

> In this case, if I paste the large file, I do see almost the start
> of the file (I seem to lose just the first line, which rolls off the
> top), and ^C still works, returning to the prompt with return code
> 130.
> 
> (I don't know whether all terminals behave like this: I just use
> xterm myself.)

This should work if the terminal and the shell both support
bracketed paste.

I suppose that all the terminals do. And rxvt is even better:
it asks for confirmation when there is a control character,
such as a newline, in the data to be pasted. IMHO, it would
be a good idea if other terminals could have such a feature.
This would avoid my issue completely.

And concerning the shells, both bash and zsh do.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> This might be a limitation of Linux's pty(7) subsystem.  The xterm
> manpage mentions the following:
> 
> ,
> | BUGS
> |  Large pastes do not work on some systems.  This is not a bug in
> |  xterm; it is a bug in the pseudo terminal driver of those systems.
> |  Xterm feeds large pastes to the pty only as fast as the pty will
> |  accept data, but some pty drivers do not return enough information
> |  to know if the write has succeeded.
> `
> 
> See also https://bugs.debian.org/273194 in xterm.  Disclaimer: I do not
> have any expertise in that area.

Thanks. Since several terminals are affected (I've tested xterm,
mlterm and GNOME Terminal), with exactly the same behavior, each
after 4095 characters, this is probably this bug.

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

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Greg Wooledge]

On Sun, Jan 22, 2023 at 07:54:39PM +, Richmond wrote:
> > 3. Type Ctrl-C (one or several times) in the terminal.
> > But nothing happens.
> You could try pressing ctrl-z at this point to send the application into
> background.

It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
The xterm's pty's input buffer is full, and it simply ignores all keyboard
input from that point forward.

(Are people not actually *testing* these things before proposing them?)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Richmond]

Vincent Lefevre wrote:
> The following issue is reproducible in several terminals, e.g. xterm
> and GNOME Terminal, and several shells, e.g. bash and zsh.
>
> 1. From the shell in an X terminal emulator, run an X application
> in foreground, e.g. emacs-gtk or xterm.
>
> 2. Paste a long text (e.g. the contents of /usr/share/doc/libc6/copyright
> to choose an example every one has) in the terminal. Actually, only
> the beginning of the text appears in the terminal.
>
> 3. Type Ctrl-C (one or several times) in the terminal.
> But nothing happens.
You could try pressing ctrl-z at this point to send the application into
background.

fg would bring it into foreground again.

I am not going to send that document into a terminal. It has asterisks
in it, what would happen if there were a line break and the next
characters were rm * ?

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Sun 22 Jan 2023 at 07:16:47 (-0500), songbird wrote:
> Vincent Lefevre wrote:
> ...
> > Is there any way to avoid this issue?
> 
>   i'm not able to test either of these on your setup but
> perhaps you can?
> 
>   does it make any difference if you set the scrolling to
> unlimited in your terminal profile?  (i have this option
> in my terminal).

The amount visibly pasted into my xterm is exactly 4096 characters.
With the file in question, file:///usr/share/doc/libc6/copyright,
it's only 86 lines long:

$ wc /tmp/bit
  86  606 4096 /tmp/bit
$ 

>   also have you ever used xclip and would that make a
> difference?

I don't see what xclip buys you. If you have two windows open,
the xterm and the child application, and you click the middle
mouse button in the xterm by mistake instead of the child,
xclip will paste into the xterm in just the same way as the
OP described originally.

Were you to use   xclip -o   in some xterm to do the pasting,
instead of the mouse's middle button, how would you redirect
xclip's output to the open child process?

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[songbird]

Vincent Lefevre wrote:
...
> Is there any way to avoid this issue?

  i'm not able to test either of these on your setup but
perhaps you can?

  does it make any difference if you set the scrolling to
unlimited in your terminal profile?  (i have this option
in my terminal).

  also have you ever used xclip and would that make a
difference?

  these are the only things i can think of.


  songbird

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Sat 21 Jan 2023 at 23:04:30 (-0600), David Wright wrote:
> On Sun 22 Jan 2023 at 05:17:09 (+0100), Vincent Lefevre wrote:
> > On 2023-01-21 21:19:06 -0600, David Wright wrote:
> > > On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > > But nothing happens.

> > > > Is there any way to avoid this issue?
> > > 
> > > Make sure that the application's data is saved, eg, ^X^S in emacs,
> > > but don't exit the application, eg, ^X^C in emacs.
> > > 
> > > Then click on the X that closes the xterm window, which takes
> > > down both xterm and the application with it. This is effectively
> > > an out-of-band signal.
> > 
> > This is what I've sometimes done until now, but in general,
> > I don't want to lose the work I've done in the shell, such
> > as temporary variable settings or things related to the
> > background jobs.

I did try out sending various signals to the bash process.
Some, like HUP, close the xterm and its emacs child, but
there are signals, like ABRT, that close the xterm but
leave the child in the care of /sbin/init.

So, for example, you can still paste your large copy into
the (emacs) child and at least get that safely stored.

But I didn't find any signal that could regain control of
bash once you've given it indigestion, so the & idea is
still my only suggestion.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Sun 22 Jan 2023 at 18:59:54 (+1100), Keith Bainbridge wrote:

> Isn't it shft-ctrl-c to copy from x-term?

Just to clarify: I didn't try to copy /from/ an xterm, I pasted
/into/ the xterm, "accidently" on purpose of course.

I used my normal MO to source the large paste, ie I typed ^A^C
in Firefox.

FWIW I don't see any effect from holding Shift while typing ^C
in xterm.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Sven Joachim]

On 2023-01-22 05:17 +0100, Vincent Lefevre wrote:

> On 2023-01-21 21:19:06 -0600, David Wright wrote:
>> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
>> > 3. Type Ctrl-C (one or several times) in the terminal.
>> > But nothing happens.
>>
>> I presume that's because the input buffer is already full, so
>> you'd need what I think they called an out-of-band signal,
>> like pressing Break used to do on an old teletype terminal.
>
> Why doesn't the terminal have a function to flush and discard
> the input buffer or have some reserved space for the intr and
> quit characters? Or automatically increase the size of the
> input buffer?

This might be a limitation of Linux's pty(7) subsystem.  The xterm
manpage mentions the following:

,
| BUGS
|  Large pastes do not work on some systems.  This is not a bug in
|  xterm; it is a bug in the pseudo terminal driver of those systems.
|  Xterm feeds large pastes to the pty only as fast as the pty will
|  accept data, but some pty drivers do not return enough information
|  to know if the write has succeeded.
`

See also https://bugs.debian.org/273194 in xterm.  Disclaimer: I do not
have any expertise in that area.

Cheers,
   Sven

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Keith Bainbridge]

Sorry if this comes as a top post. I can't see the original text here


Isn't it shft-ctrl-c to copy from x-term?

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Sun 22 Jan 2023 at 05:17:09 (+0100), Vincent Lefevre wrote:
> On 2023-01-21 21:19:06 -0600, David Wright wrote:
> > On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > But nothing happens.
> > 
> > I presume that's because the input buffer is already full, so
> > you'd need what I think they called an out-of-band signal,
> > like pressing Break used to do on an old teletype terminal.
> 
> Why doesn't the terminal have a function to flush and discard
> the input buffer or have some reserved space for the intr and
> quit characters? Or automatically increase the size of the
> input buffer?

IDK, I've never tried to write programs for the X system itself.

> > > Is there any way to avoid this issue?
> > 
> > Make sure that the application's data is saved, eg, ^X^S in emacs,
> > but don't exit the application, eg, ^X^C in emacs.
> > 
> > Then click on the X that closes the xterm window, which takes
> > down both xterm and the application with it. This is effectively
> > an out-of-band signal.
> 
> This is what I've sometimes done until now, but in general,
> I don't want to lose the work I've done in the shell, such
> as temporary variable settings or things related to the
> background jobs.

The only suggestion I can give is that you start the applications
concerned with &, so that you get the xterm prompt back. In this
case, if I paste the large file, I do see almost the start of the
file (I seem to lose just the first line, which rolls off the top),
and ^C still works, returning to the prompt with return code 130.

(I don't know whether all terminals behave like this: I just use
xterm myself.)

It's not a habit I use myself, because for some reason, I don't
happen to make that mistake. That might be because I put the cursor
very central in the emacs window when I paste large sections of text,
and that's because I have (setq mouse-yank-at-point t), which inserts
the text at point, not the cursor position.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-21 21:19:06 -0600, David Wright wrote:
> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > 3. Type Ctrl-C (one or several times) in the terminal.
> > But nothing happens.
> 
> I presume that's because the input buffer is already full, so
> you'd need what I think they called an out-of-band signal,
> like pressing Break used to do on an old teletype terminal.

Why doesn't the terminal have a function to flush and discard
the input buffer or have some reserved space for the intr and
quit characters? Or automatically increase the size of the
input buffer?

> > Is there any way to avoid this issue?
> 
> Make sure that the application's data is saved, eg, ^X^S in emacs,
> but don't exit the application, eg, ^X^C in emacs.
> 
> Then click on the X that closes the xterm window, which takes
> down both xterm and the application with it. This is effectively
> an out-of-band signal.

This is what I've sometimes done until now, but in general,
I don't want to lose the work I've done in the shell, such
as temporary variable settings or things related to the
background jobs.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> The following issue is reproducible in several terminals, e.g. xterm
> and GNOME Terminal, and several shells, e.g. bash and zsh.
> 
> 1. From the shell in an X terminal emulator, run an X application
> in foreground, e.g. emacs-gtk or xterm.
> 
> 2. Paste a long text (e.g. the contents of /usr/share/doc/libc6/copyright
> to choose an example every one has) in the terminal. Actually, only
> the beginning of the text appears in the terminal.

Well, strictly, I see the end of the first portion of the pasted file.
The input buffer of xterm fills up, ironically at "Por" in one of the
lines containing "Portions Copyright … …". The beginning of the file
/usr/share/doc/libc6/copyright has scrolled off the top by then.

> 3. Type Ctrl-C (one or several times) in the terminal.
> But nothing happens.

I presume that's because the input buffer is already full, so
you'd need what I think they called an out-of-band signal,
like pressing Break used to do on an old teletype terminal.

> 4. Quit the X application that was started at step 1.
> 
> Result: many lines of the pasted text are executed by the shell!
> 
> This issue doesn't occur when the pasted text is short: the Ctrl-C
> kills the X application via a SIGINT and nothing is executed.

Yes, because in this case, ^C makes it into the input to xterm.

> You may wonder why one would paste a long text at step 2. In fact,
> this happens by accident: I sometimes paste data in the terminal
> instead of the application (typically Emacs). And this is really
> annoying, in particular when lines contains the ">" character,
> which has the effect to create files.
> 
> Is there any way to avoid this issue?

Make sure that the application's data is saved, eg, ^X^S in emacs,
but don't exit the application, eg, ^X^C in emacs.

Then click on the X that closes the xterm window, which takes
down both xterm and the application with it. This is effectively
an out-of-band signal.

Finally, open another xterm with your WM's menu, to replace it.

Cheers,
David.

Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

The following issue is reproducible in several terminals, e.g. xterm
and GNOME Terminal, and several shells, e.g. bash and zsh.

1. From the shell in an X terminal emulator, run an X application
in foreground, e.g. emacs-gtk or xterm.

2. Paste a long text (e.g. the contents of /usr/share/doc/libc6/copyright
to choose an example every one has) in the terminal. Actually, only
the beginning of the text appears in the terminal.

3. Type Ctrl-C (one or several times) in the terminal.
But nothing happens.

4. Quit the X application that was started at step 1.

Result: many lines of the pasted text are executed by the shell!

This issue doesn't occur when the pasted text is short: the Ctrl-C
kills the X application via a SIGINT and nothing is executed.

You may wonder why one would paste a long text at step 2. In fact,
this happens by accident: I sometimes paste data in the terminal
instead of the application (typically Emacs). And this is really
annoying, in particular when lines contains the ">" character,
which has the effect to create files.

Is there any way to avoid this issue?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Error: Unable to create output file 'C:\TC20\OUTPUT\MAYOR.obj'

[William Torrez Corea]

I install Dosbox and Tc20 in Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux

> sudo apt install dosbox

Tc20 was installed with wine-5.0.3 (Debian 5.0.3-3) in the following PATH:

> .wine/drive_c/TC20

TC20 was mounted in the emulator DOSBox version 0.74-3

># Lines in this section will be run at startup.
># You can put your MOUNT lines here.

>mount c: .wine/drive_c/TC20
>c:
>cd TC20
>cd BIN
>TC.exe

But when i try compile the code, exist the following problem:

>Error: Unable to create output file 'C:\TC20\OUTPUT\MAYOR.obj'

Try to change the directories in the emulator Dosbox, but the resulted
is the same.

>C:\TC20\INCLUDE
>C:\TC20\LIB\
>C:\TC20\OUTPUT
>C:\TC20\


-- 

With kindest regards, William.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Bijan Soleymani]

On 6/13/2022 1:57 AM, Bijan Soleymani wrote:
So again your choices in practice are assembly, C, a subset of C++ 
(essentially C + classes, but no standard library and practically no 
templates due to stack limitation), maybe rust or some language you 
design yourself. 


Here's a blog post about kernel drivers on Windows in Rust, turns out 
that just like C++ you can't use the standard library in rust:


https://not-matthias.github.io/posts/kernel-driver-with-rust/

"Rust provides lots of abstractions in thestandard library 
<https://doc.rust-lang.org/std/>which cannot be used in the kernel 
because it uses the Windows API behind the scenes. Thanks to the awesome 
language design, we can remove the standard library by specifying 
the|#![no_std]|attribute in|main.rs|."


The same thing would apply to linux, as there are almost certainly 
usermode/(g)libc calls in the rust standard library that you can't make 
from the kernel.


Bijan

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Bijan Soleymani]

On 2022-05-30 05:12, Susmita/Rajib wrote:


Could I please be given a little more guidance on the following aspects 
please?:

(1)   exhaustive example codes


All Debian main packages have source code as they are free software.


(2)   object library resources, references, explanations, et al


All Debian main libraries have source code as they are free software.


(3)   Whether Eclipse could be used for c++


Yes, it can.


(4)   Whether Device Drivers and other lower-level programs could be
designed with c++, like they are done in c or assembly level languages
(I am aware that KDE was written in c++, but ...).


Yes with severe limitations as I described in my previous email.


(5)   Whether optimisation tools like valgrind and gdb are available
for c++ also


Yes I have used valgrind and gdb on C++.

However kernel mode debugging (for kernel or device drivers) can't use 
valgrind and needs a special debugger (this exists now for Linux but I 
don't think it did when I started using Linux 20+ years ago).



Please feel free to post any other general guidance and advice please,
considering that you are actually talking to a novice.


My advice is take advantage of the fact that Debian and all its software 
are free software (open source). Grab the code for some program you use 
and compile it then modify it to suit your needs. You will find this 
hard. But software is hard. This is something you need to accept. It is 
not primarily because people have done a bad job writing the software. 
It is reality.


As an intellectual philosophical read I recommend in the beginning was 
the command line by Neal Stephenson.


https://web.archive.org/web/20180218045352/http://www.cryptonomicon.com/beginning.html

To quote the end (apologies for the length):

THE RIGHT PINKY OF GOD


In his book The Life of the Cosmos, which everyone should read, Lee 
Smolin gives the best description I've ever read of how our universe 
emerged from an uncannily precise balancing of different fundamental 
constants. The mass of the proton, the strength of gravity, the range of 
the weak nuclear force, and a few dozen other fundamental constants 
completely determine what sort of universe will emerge from a Big Bang. 
If these values had been even slightly different, the universe would 
have been a vast ocean of tepid gas or a hot knot of plasma or some 
other basically uninteresting thing--a dud, in other words. The only way 
to get a universe that's not a dud--that has stars, heavy elements, 
planets, and life--is to get the basic numbers just right. If there were 
some machine, somewhere, that could spit out universes with randomly 
chosen values for their fundamental constants, then for every universe 
like ours it would produce 10^229 duds.


Though I haven't sat down and run the numbers on it, to me this seems 
comparable to the probability of making a Unix computer do something 
useful by logging into a tty and typing in command lines when you have 
forgotten all of the little options and keywords. Every time your right 
pinky slams that ENTER key, you are making another try. In some cases 
the operating system does nothing. In other cases it wipes out all of 
your files. In most cases it just gives you an error message. In other 
words, you get many duds. But sometimes, if you have it all just right, 
the computer grinds away for a while and then produces something like 
emacs. It actually generates complexity, which is Smolin's criterion for 
interestingness.


Not only that, but it's beginning to look as if, once you get below a 
certain size--way below the level of quarks, down into the realm of 
string theory--the universe can't be described very well by physics as 
it has been practiced since the days of Newton. If you look at a small 
enough scale, you see processes that look almost computational in 
nature.


I think that the message is very clear here: somewhere outside of and 
beyond our universe is an operating system, coded up over incalculable 
spans of time by some kind of hacker-demiurge. The cosmic operating 
system uses a command-line interface. It runs on something like a 
teletype, with lots of noise and heat; punched-out bits flutter down 
into its hopper like drifting stars. The demiurge sits at his teletype, 
pounding out one command line after another, specifying the values of 
fundamental constants of physics:


universe -G 6.672e-11 -e 1.602e-19 -h 6.626e-34 -protonmass 
1.673e-27


and when he's finished typing out the command line, his right pinky 
hesitates above the ENTER key for an aeon or two, wondering what's going 
to happen; then down it comes--and the WHACK you hear is another Big 
Bang.


Now THAT is a cool operating system, and if such a thing were actually 
made available on the Internet (for free, of course) every hacker in the 
world would download it right away and then stay up all night long 
messing with it, spitting out universes 

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Bijan Soleymani]

On 2022-06-13 01:57, Bijan Soleymani wrote:

On 2022-05-30 13:01, Susmita/Rajib wrote:

I was trying to find out if c++ could be used to build device drivers.
You said, "... Linux drivers are written in C, but technically you can
mix languages: use C++ and link it against C ...". But I would request
more specificity here:    (a)  if c++ could be used without using any
other programming language to build a device driver. (b)  If it is
practised industrially.


I work on a kernel mode driver for windows. It is written in C++. But
we can't use the C++ standard library, as Windows kernel mode doesn't
support exceptions. I think someone managed to make a version that did
but it never ended up being good enough to catch on.


Sorry this last bit wasn't clear. Someone made a version of the standard 
library that didn't use exceptions. But it wasn't that useful probably 
because of all the other limitations I mentioned.


Also before this I worked on a user space mobile app library. The 
initial version was in Java with only the cryptography done in C and 
accessed via JNI. This was because we started on Android and the server 
was written in Java.


But iOS (iPhones) doesn't run Java, so we had to move the core to C, and 
access that from Java/Kotlin on Android using JNI and from objective 
C/swift on iOS using the standard C interface.


Otherwise the Android and iOS implementations would need to be 
duplicated.


We could have done the core in C++ or objective C, but C had less 
headaches with portability.


Before this I worked on another project in perl (my code) and ruby (an 
existing software component) on Linux but it needed heavy access to OS 
syscalls to monitor file accesses (inotify), and so I had to have a 
C/C++ component that did the file access monitoring that the ruby/perl 
code needed to communicate with.


Bijan

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Bijan Soleymani]

On 2022-05-30 13:01, Susmita/Rajib wrote:

I was trying to find out if c++ could be used to build device drivers.
You said, "... Linux drivers are written in C, but technically you can
mix languages: use C++ and link it against C ...". But I would request
more specificity here:    (a)  if c++ could be used without using any
other programming language to build a device driver. (b)  If it is
practised industrially.


I work on a kernel mode driver for windows. It is written in C++. But we 
can't use the C++ standard library, as Windows kernel mode doesn't 
support exceptions. I think someone managed to make a version that did 
but it never ended up being good enough to catch on.


Also stack space is tiny in kernel mode so you can't put much on the 
stack.


And you can't allocate memory at high IRQ level (when handling 
interrupts or in certain calls you will get from the OS).


Also at the high IRQ levels you can't access paged memory. Because you 
will die if the memory is not paged in (you can't have a page fault).


This means you have to deal with paged and non paged memory specifically 
with intention.


Also all kernel mode OS functions in windows (Linux syscall equivalents 
in windows) are C functions (as are most user mode OS functions in 
windows).


So you are limited to languages that allow you to control allocation 
(paged vs non paged) and deal with a stack size of a few kilobytes. And 
also to deal with CPU physical vs virtual memory vs GPU physical and 
virtual memory (I work on a graphics driver). So that means pointers.


So everything except assembly, C and C++ is out. Maybe rust I don't know 
but I think rust has something to manage allocations and someone would 
have to rewrite that to work in kernel mode and deal with all that.


So again your choices in practice are assembly, C, a subset of C++ 
(essentially C + classes, but no standard library and practically no 
templates due to stack limitation), maybe rust or some language you 
design yourself.


Best wishes,
Bijan

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Susmita/Rajib]

Dear Mr. King,

I totally agree with what you say regarding diversity in range of
problems requiring different solutions. Perhaps that agreement was
also reflected in my earlier post at
https://lists.debian.org/debian-user/2022/05/msg00854.html

The higher order truth that I am trying to arrive at is that we can
have only a very limited cognitive gifts. A beyond-human level AI will
be unrestricted by such limitations.

In my other post to Mr. DdB at
https://lists.debian.org/debian-user/2022/05/msg00857.html I said that
I was fortunate to have read some on Beyond. I overlooked to mention
Dr. Steven Greer and his work there.

Reality is One. Our limited cognitive abilities makes it appear
piece-meal, we approach them piece-meal and we try to solve our
problems piece-meal. We don't realise that we don't address the Big
Picture. Also that how Big is this Big.

But as I have promised to myself in the post at
https://lists.debian.org/debian-user/2022/05/msg00854.html, I shall
continue to make tiny inroads into Python until the Singularity
arrives.

Thank you for educating me, like Mr. Ilya Kazakevich
,Mr. Joe  and Mr. Edwin Zimmerman
 did, and you all have my admiration for that.

Best wishes,
Rajib





To: debian-user@lists.debian.org
Subject: Re: How should learning to program in c++ be approached,
if learning objectives are sought to be customised?
From: Alex King 
Date: Wed, 1 Jun 2022 12:29:32 +1200
Message-id: <[🔎] bb9ae618-bbbe-e557-5150-aadf49615...@rimuhosting.com>
In-reply-to: <20220530172154.308ba20...@bendel.debian.org>
References: <20220530172154.308ba20...@bendel.debian.org>

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Alex King]

Hey Rajib,

Your questions to the list have been well answered already, but a couple 
more points may be helpful.  I'm a part-time programmer who's learnt C 
and Python, and I'm currently learning Rust.


On 31/05/22 05:21, debian-user-digest-requ...@lists.debian.org wrote:

Hello!

You said, "... C++ would be much easier to learn once you understand C ..."
I learnt c, but didn't like it, as I didn't find a list of specific
(As already mentioned, C++ would be harder to learn than C, since you 
have to learn C first)



modules (or reusable example code-snippets) to achieve an objective.
The header files are very, very complex and they can't be understood.
The header files use machine language and push those obscure portions
into tiny little black boxes, under the carpet, away from our sight. I
used cscope to read the header files and understand them, but in vain.
To me, c appears as a hodge podge of low level and high level
programming languages. Not a complete programming language in itself.
c language appears to encourage a complex ecosystem of numerous
programmers coming from diverse fields, all working as individual
parts of a very complex machinery.
But c ecosystem appears to discourage a complete programmer who has a
complete idea of the entire machinery and its individual components. A
slight imbalance in super-specialisation could bring down an entire
system.


To master a language for practical purposes, you have to learn the 
libraries.  I found the same problem as you did when learning Python and 
Rust.  I had the basics of the language, but wasn't sure how to take the 
next steps.  E.g. opening and reading/writing to files.


The standard library documentation for both Python and Rust are 
comprehensive, but until you build up some fluency with the 
documentation and the language concepts that are being used, they are 
incomprehensible, and/or difficult to find the right documentation to 
look at.  With Python in particular, it took me many years (of part time 
programming) to become familiar enough to be really comfortable.


I think you are experiencing the same thing with C.  (I probably did too 
but it's so long ago I don't remember.)


Part of the problem is also the platform you are programming for.  At 
the same time as learning a language, you also need to learn the 
platform.  For Debian/Linux/UNIX, the book "Advanced Programming in the 
UNIX Environment" by Rago and Stevens will apparently help (I never had 
it, but it is well recommended.)

...

back. Java isn't used for building device drivers for the industry, so
far as I have gathered.




Regarding my note, "...  had a programming language been developed
that could address both the lowest microprocessor(machine)-level to
the most advanced user level programming, reading, comprehension and
application  ...", you said, "... Python should be your choice! ..."
Is it supposed to mean that theoretically, an entire OS could be built
up from scratch using Python? Including device drivers?
You said, "... there is even MicroPython for microcontrollers ...". So
according to your comment, python should be able to build a device
driver as well as an OS. And there already exist such implementations.

As already said, the language best used for device drivers depends on 
the kernel you are writing for.  C for Debian (linux) etc.


If you write your own kernel, you can write it in any language you like. 
 Writing a kernel in Python is possible, but you need to also write 
some support code in another language (indeed the same for C or rust). 
You have the problem of bootstrapping your python interpreter early in 
boot.  And being interpreted and with a garbage collector, it may be 
difficult to write code in python that performs well in real-time.  This 
may limit what your OS can do.  But the point is an OS kernel could be 
written in any language, normally you would write your device drivers in 
the same language as the kernel or at least a compatible one.



I often wonder aloud why c wasn't re-built to have the modularity and
OOP structure of Java. It would definitely have helped. Yes, I know
that the demand wasn't there, when programmers thought that 1024KB
would address all problems of the world.

But a language could be re-built to incorporate every programming
need. Then aided by a huge library of code snippets, functions,
objects, etc., like Oracle Java repository. But to reach the lowest
level possible.
Something that suits every need is impossible.  I think they tried that 
with Ada.


I began learning python, but I am not sure if python could be used in
place of Assembly (or machine) Language, addressing programming needs
from the lowest to the highest level. Perhaps your notes answer my
doubts. Would like to know more.



Indeed, python is not the best language for an OS kernel, even if it's 
possible.  A

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Susmita/Rajib]

Dear Mr. DdB,
Thank you for your off-list email. Fortunately it seems I didn't send
you an off-list email, because of which your Filters couldn't act upon
it.
It is strange that it was only recently, despite it having been
published in 1991, The Holographic Universe, by Michael Talbot,
reached me. It took me to Holotropic Breathwork, by Prof. Stanislav
Groff. I had also read The Simulation Hypothesis by Nick Bostrom, but
these two caused goosebumps. Our ancient Bharatiya Texts, collectively
called the Vedic Upanishad, describe the Illusory Construct in
details.
May be, we could find a way to communicate with each other off-list in future.
Best wishes,
Rajib
Etc.

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Emanuel Berg]

Susmita/Rajib wrote:

> My dear Illustrious List Maintainers, Programmers and Senior
> members, particularly, Ilya Kazakevich ,
> Joe  and Edwin Zimmerman
> ,
>
> I am overwhelmed by the supremely patient explanations by
> Mr. Ilya Kazakevich. The time he has spent in reasoning and
> writing emails compels me to bow in deep respect.
>
> I was certain that I didn't have the mettle to be a computer
> programmer. To me a programmer's hyperfocus for an extended
> period of time, ignoring the rest of the information and
> irrationalities as noise, internal auto-processing neural
> networks even with a limited and fragile mind are beyond my
> abilities. [...]

Touching over-respect from a non-programmer ... spend the time
you wrote in this thread coding whatever in whatever langauge
I'm sure you'd come up with something. After that it's just
a matter of doing the same thing, more.

-- 
underground experts united
https://dataswamp.org/~incal

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Susmita/Rajib]

My dear Illustrious List Maintainers, Programmers and Senior members,
particularly, Ilya Kazakevich , Joe  and
Edwin Zimmerman ,

I am overwhelmed by the supremely patient explanations by Mr. Ilya
Kazakevich. The time he has spent in reasoning and writing emails compels
me to bow in deep respect.

I was certain that I didn't have the mettle to be a computer programmer. To
me a programmer's hyperfocus for an extended period of time, ignoring the
rest of the information and irrationalities as noise, internal
 auto-processing neural networks even with a limited and fragile mind are
beyond my abilities. Thank you, programmers. It is because of you that the
world is gradually becoming a better place to live in.

I completely agree with what Mr. Joe says: "... The idea of learning the
functions and interfaces of every library ever written for C is not a
trivial one, and when you finish you'll find another few thousand were
written while you were doing it ..."

I am not saying that "... there should be a definitive set of libraries,
and nobody should ever be permitted to extend this set ...". I agree with
Mr. Joe that this is impossible.

What I expect instead is One flexible, evolve-able programming language
that addresses all requirements. Presently, every computing niche has its
own programming environment and language.

Because of my natural tendency towards holism, I tend to expect a
programming environment that would address computing needs from the lowest
level of programming microprocessors, microcontrollers, et al, to the
highest humanly imaginable levels of complexities.

I also agree that I find myself lost amidst the bewildering diversity of
programming languages, where computation is necessary, when I am concerned
that the scenario would compel me to be a seamless cog of the huge system
working in harmony with the rest of the ecosystem and getting "lost". What
puts me off is that this ecosystem is subject to "default automated
reactive mammalian-limbic self-preservation mechanisms". We aren't exactly
rational. Our rationality is just a thin veneer of the neocortex.

A little child, with a bundle of flexible Neural Networks, but not so
"aware/conscious" like us, is capable of working like Neural Networks do at
a subconscious level. As we grow up and we become "aware" of our own
selves, as our bicameral mind breaks down, we lose the ability to "lose
ourselves" in the task that we have at hand. At least, I try to look at the
Big Picture always, which puts me off very easily, in the matters of
programming.

Ideally, I would have liked to enter into an Education system, learn about
finer aspects and nitty gritty, find a niche or get off it. But this is
difficult. Hopefully, gifted ones like you shall herald the advent of AI
systems. Then we shall have a societal system encouraging a positive use of
Leisure.

I hope that within my lifetime we shall have, because of your continual
collaborative perseverance, the good fortune to witness a beyond-human
level AI. I noted that currently, research in AI like Deepmind's Alpha Code
AI, writing customised codes as per requirements, AlphaFold AI, StyleGAN,
OpenAI, NVidia's EditGAN and so on, are gradually taking on an exponential
growth curve.

In the meanwhile I shall continue to make tiny inroads into Python, rather
than c++, a big thanks to Mr. Kazakevich, and keep myself prepared until
the Big Change arrives.

Best wishes.
Rajib
Etc.


To: Debian Users 
Subject: Re: How should learning to program in c++ be approached, if
learning objectives are sought to be customised?
From: IL Ka 
Date: Mon, 30 May 2022 23:12:06 +0300
Message-id: <[🔎] CAHv=rM0VhDB2iRRaM9_umDyDVoddFqLEL2h3UQen=
j-4gu3...@mail.gmail.com>
In-reply-to: <[🔎] CAEG4cZVupq=
sv0xh57vnt_rnetjpxx549qm2no_tkl4qzf_...@mail.gmail.com>
References: <[🔎]
caeg4czwmot23cvnbg_rrag0gbwciot-up2v117tzg+knf2c...@mail.gmail.com>
 <[🔎]
caeg4czuprknrlspmhzsongirggxfptmlqe56weh8aakvjkf...@mail.gmail.com> <[🔎]
CAEG4cZVupq=sv0xh57vnt_rnetjpxx549qm2no_tkl4qzf_...@mail.gmail.com>

[   ...   snipped   ...   ]

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Edwin Zimmerman]

On 5/30/22 15:58, Joe wrote:
> You pick the programming language (and OS, and
> hardware platform) to suit the job to be done, not the other way
> around.
Absolutely spot on!  If you want to write a device driver, you need to look at 
the operating system the driver will run on and see what programming language 
the documentation suggests.  On linux, that will be either C or in a few new 
cases Rust.  A driver for Windows would most likely be written in C++.  I'm not 
familiar with programming Mac or mobile platforms, but I know they have their 
preferred languages as well.  If you are writing a user-space tool or program, 
you probably want to look in a different direction than C++.

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Timothy M Butterworth]

On Mon, May 30, 2022 at 1:18 PM Susmita/Rajib  wrote:

> Hello!
>
> A wonderfully informative email indeed. It entices me to more specific
> questions.
>
> I would like to partially quote you to maintain a context for my reply.
>
> You said, "... C++ would be much easier to learn once you understand C ..."
> I learnt c, but didn't like it, as I didn't find a list of specific
> modules (or reusable example code-snippets) to achieve an objective.
> The header files are very, very complex and they can't be understood.
> The header files use machine language and push those obscure portions
> into tiny little black boxes, under the carpet, away from our sight. I
> used cscope to read the header files and understand them, but in vain.
> To me, c appears as a hodge podge of low level and high level
> programming languages. Not a complete programming language in itself.
> c language appears to encourage a complex ecosystem of numerous
> programmers coming from diverse fields, all working as individual
> parts of a very complex machinery.
> But c ecosystem appears to discourage a complete programmer who has a
> complete idea of the entire machinery and its individual components. A
> slight imbalance in super-specialisation could bring down an entire
> system.
>
> I was really excited by the scope provided by Java. It appeared so
> easy to me that I could easily build a functional program, to aid
> memorising alphabets abcd... in the reverse, "which alphabet came
> before which alphabet" using a random function, in a graphical
> environment.
>
> I had read that Java could be used to build an entire Operating System
> up by itself. In essence, therefore, device drivers as well.
> Unfortunately, that project of building an OS in Java was dropped long
> back. Java isn't used for building device drivers for the industry, so
> far as I have gathered.
>
> Regarding my note, "...  had a programming language been developed
> that could address both the lowest microprocessor(machine)-level to
> the most advanced user level programming, reading, comprehension and
> application  ...", you said, "... Python should be your choice! ..."
> Is it supposed to mean that theoretically, an entire OS could be built
> up from scratch using Python? Including device drivers?
> You said, "... there is even MicroPython for microcontrollers ...". So
> according to your comment, python should be able to build a device
> driver as well as an OS. And there already exist such implementations.
>
> I was trying to find out if c++ could be used to build device drivers.
> You said, "... Linux drivers are written in C, but technically you can
> mix languages: use C++ and link it against C ...". But I would request
> more specificity here:(a)  if c++ could be used without using any
> other programming language to build a device driver. (b)  If it is
> practised industrially.
>
> I often wonder aloud why c wasn't re-built to have the modularity and
> OOP structure of Java. It would definitely have helped. Yes, I know
> that the demand wasn't there, when programmers thought that 1024KB
> would address all problems of the world.
>
> But a language could be re-built to incorporate every programming
> need. Then aided by a huge library of code snippets, functions,
> objects, etc., like Oracle Java repository. But to reach the lowest
> level possible.
>

The problem with JAVA is Oracle. If you build something good that goes into
main stream use you risk Oracle suing you like they are with Google
Android.

I began learning python, but I am not sure if python could be used in
> place of Assembly (or machine) Language, addressing programming needs
> from the lowest to the highest level. Perhaps your notes answer my
> doubts. Would like to know more.
>
> For example, like Deepmind's Alpha Code AI, writing codes as per
> requirements, research is getting there.
> So I would like to develop an understanding of programming from the
> lowest level to the highest level. The way programming is approached
> in textbooks doesn't suit me. I can't have the flexibility to use
> programming like a cobweb or a network, jumping from lowest level to
> the highest level according to my need.
>
> I read that micropython is written in c. So it is just like
> circumlocuting to the same point from where it began.
>
> So confusing!
>
> Hope that some confusions shall be set aside in your subsequent posts.
>
> You also said, "... debian-gcc maintainers maintain the gcc package
> for Debian, they are not responsible for teaching people C or C++ ..."
>
> I didn't expect them to teach, but only to share th

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[IL Ka]

>
>
> The header files are very, very complex and they can't be understood.
>
No reason to read header files.
Both C and C++ have ANSI standards, which developers code against.
Just read standard and do not bother with reading header files.
But start with a good book.

Studying C by reading header files is like studying linux by reading kernel
source code instead of man pages)


> To me, c appears as a hodge podge of low level and high level
> programming languages.

Yes, C is a pretty low level language. Do not use it to build websites or
mobile bank clients: it is possible, but not convenient.



> I was really excited by the scope provided by Java. It appeared so
> easy to me that I could easily build a functional program, to aid
> memorising alphabets abcd... in the reverse, "which alphabet came
> before which alphabet" using a random function, in a graphical
> environment.
>
Java is a good language (Kotlin also good and has full interop with Java)
Debian provides OpenJDK package and could be used to do Java development.
Intellij Idea Community edition is a free IDE for Java that also works on
Debian.

Many enterprise systems and mobile applications (Android is based on Linux)
are written on Java and Kotlin.


>
> I had read that Java could be used to build an entire Operating System
> up by itself. In essence, therefore, device drivers as well.
>
Well, any turing-complete language could be used to build anything (this is
what CS professors tell us)
The question is whether it is convenient or not, and how much time does
it take.

If you have unlimited time and do not care about performance, you can write
OS on bash:
just create an LLVM backend that compiles bash to the assembler for your
CPU.


Once there was a specification of CPU to run JVM on (google for "picoJava")
Not sure if it exists IRL, but if it does -- you can run Java on bare
metal:)



> Unfortunately, that project of building an OS in Java was dropped long
> back. Java isn't used for building device drivers for the industry, so
> far as I have gathered.
>

There are several problems with high level languages for driver development.
* Garbage collection complicates direct memory management (and many devices
use MMIO) and also makes code less predictable (you can't predict when
memory will be freed)
* Most OSes have C API, and Java-C interop is awkward
* To run Java you need to either run JVM in the kernel or compile Java to
the native code (JVM compiles Java to the native code while running (JIT)
but not before)
Technically, you can run JVM in the kernel (there are several virtual
machines in the kernel already: for AML, ebpf etc) but it will pollute the
kernel and sounds like an anecdote.
Even java code compiled into the native code needs runtime (for GC) and
nobody will add such runtime to the kernel.

Most kernel developers are happy with "C" and suggesting them to use Java
for kernel development is like suggesting Linux sysadmin to use Windows:
probably a bad idea.

While in theory any language can be used for anything, practically there is
no one language to fit it all.

People use one language to build a website and another language to write
device drivers.



> Is it supposed to mean that theoretically, an entire OS could be built
> up from scratch using Python? Including device drivers?
>

That means you can build a robot and program it in Python.

Honestly, I do not think device drivers are the right things to start
programming with.
Find a language that you like (be it Java, Python,  C#, Ruby, whatever) and
write software!



> You said, "... Linux drivers are written in C, but technically you can
> mix languages: use C++ and link it against C ...". But I would request
> more specificity here:(a)  if c++ could be used without using any
> other programming language to build a device driver. (b)  If it is
> practised industrially.
>

In OS X (Apple) they have "DriverKit": C++ (class-based) API to write
drivers.
Other mainstream OSes provide C API for drivers, but again: C++ is backward
compatible with C in most cases.

C++ provides "extern "C"" to export symbols to C and can also call any C
function, so yes: you can write a driver with C++ even for Linux,
but probably you would need to disable some C++ features (like Exceptions,
probably RTTI etc).
Doing so is very hackish.

Also note that Linus hates C++. If you want to read lots of bad words, ask
him about C++ in kernel development (please, dont)


I often wonder aloud why c wasn't re-built to have the modularity and
> OOP structure of Java.

If you want to change language heavily, you have choices:
* Break backward compatibility and lose an uncountable number of code lines
and years of development. This is not what you want to do.
* Increase language complexity (this is what happened with C++). An

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Joe]

On Mon, 30 May 2022 22:31:56 +0530
"Susmita/Rajib"  wrote:


>  To me, c appears as a hodge podge of low level and
> high level programming languages. Not a complete programming language
> in itself. c language appears to encourage a complex ecosystem of
> numerous programmers coming from diverse fields, all working as
> individual parts of a very complex machinery.

C is a language core, very low level and the implementation can be very
fast, almost one-to-one with assembler.

It is completely useless by itself, and will only actually do things
with the assistance of libraries. It requires a library to read a
keyboard, write to a screen etc. There is a set of standard libraries
provided with any C implementation.

> But c ecosystem appears to discourage a complete programmer who has a
> complete idea of the entire machinery and its individual components. A
> slight imbalance in super-specialisation could bring down an entire
> system.

If you're saying there should be a definitive set of libraries, and
nobody should ever be permitted to extend this set, I think you're on a
non-starter. C itself is fully defined and easy to learn. The idea of
learning the functions and interfaces of every library ever written for
C is not a trivial one, and when you finish you'll find another few
thousand were written while you were doing it.
> 
> I was really excited by the scope provided by Java. It appeared so
> easy to me that I could easily build a functional program, to aid
> memorising alphabets abcd... in the reverse, "which alphabet came
> before which alphabet" using a random function, in a graphical
> environment.
> 
> I had read that Java could be used to build an entire Operating System
> up by itself.

That is exactly what C was written to do, specifically in order to
write Unix. See Ken Thompson and Dennis Ritchie.

> In essence, therefore, device drivers as well.
> Unfortunately, that project of building an OS in Java was dropped long
> back. Java isn't used for building device drivers for the industry, so
> far as I have gathered.

I've seen a device driver written in Delphi, which is a visual OO
Pascal. That's hardly assembly language. I rather suspect that device
drivers are written in whatever way suits the programmer, rather than
using a particularly specified language.
> 

>  But I would request
> more specificity here:(a)  if c++ could be used without using any
> other programming language to build a device driver. (b)  If it is
> practised industrially.

Why is this important to you? If you plan to spend much time writing
device drivers yourself, you will find out for yourself the most
practical way to do it. You pick the programming language (and OS, and
hardware platform) to suit the job to be done, not the other way
around.
> 
> I often wonder aloud why c wasn't re-built to have the modularity and
> OOP structure of Java. 

Isn't that basically what Stroustrup did, arguably not in the best
possible way? C++ is much older than Java, which almost certainly drew
heavily on experience with C++. But Java was designed as an interpreted
language, like Pascal, and while it can be compiled to machine code,
that wasn't really the intended usage, so it's not really built for
speed.

> Yes, I know
> that the demand wasn't there, when programmers thought that 1024KB
> would address all problems of the world.

C was written when 64K of RAM was typical, for the early minicomputers.
> 
> But a language could be re-built to incorporate every programming
> need. Then aided by a huge library of code snippets, functions,
> objects, etc., like Oracle Java repository. But to reach the lowest
> level possible.
> 
It seems to me you've pretty much described C, as well as what you said
was wrong with it.

As an aside, I've always found the best way of learning a new language
was to have a project of my own and to use the language manuals to find
out how to achieve what I needed to do. I learned Pascal on the BBC
Micro in writing a simple business program (no practical spreadsheet
for 32K of RAM), and my first C program wasn't Hello World, it was a
recursive program using pointers to optimally fit audio tracks on
cassettes.

-- 
Joe

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Susmita/Rajib]

Hello!

A wonderfully informative email indeed. It entices me to more specific
questions.

I would like to partially quote you to maintain a context for my reply.

You said, "... C++ would be much easier to learn once you understand C ..."
I learnt c, but didn't like it, as I didn't find a list of specific
modules (or reusable example code-snippets) to achieve an objective.
The header files are very, very complex and they can't be understood.
The header files use machine language and push those obscure portions
into tiny little black boxes, under the carpet, away from our sight. I
used cscope to read the header files and understand them, but in vain.
To me, c appears as a hodge podge of low level and high level
programming languages. Not a complete programming language in itself.
c language appears to encourage a complex ecosystem of numerous
programmers coming from diverse fields, all working as individual
parts of a very complex machinery.
But c ecosystem appears to discourage a complete programmer who has a
complete idea of the entire machinery and its individual components. A
slight imbalance in super-specialisation could bring down an entire
system.

I was really excited by the scope provided by Java. It appeared so
easy to me that I could easily build a functional program, to aid
memorising alphabets abcd... in the reverse, "which alphabet came
before which alphabet" using a random function, in a graphical
environment.

I had read that Java could be used to build an entire Operating System
up by itself. In essence, therefore, device drivers as well.
Unfortunately, that project of building an OS in Java was dropped long
back. Java isn't used for building device drivers for the industry, so
far as I have gathered.

Regarding my note, "...  had a programming language been developed
that could address both the lowest microprocessor(machine)-level to
the most advanced user level programming, reading, comprehension and
application  ...", you said, "... Python should be your choice! ..."
Is it supposed to mean that theoretically, an entire OS could be built
up from scratch using Python? Including device drivers?
You said, "... there is even MicroPython for microcontrollers ...". So
according to your comment, python should be able to build a device
driver as well as an OS. And there already exist such implementations.

I was trying to find out if c++ could be used to build device drivers.
You said, "... Linux drivers are written in C, but technically you can
mix languages: use C++ and link it against C ...". But I would request
more specificity here:(a)  if c++ could be used without using any
other programming language to build a device driver. (b)  If it is
practised industrially.

I often wonder aloud why c wasn't re-built to have the modularity and
OOP structure of Java. It would definitely have helped. Yes, I know
that the demand wasn't there, when programmers thought that 1024KB
would address all problems of the world.

But a language could be re-built to incorporate every programming
need. Then aided by a huge library of code snippets, functions,
objects, etc., like Oracle Java repository. But to reach the lowest
level possible.

I began learning python, but I am not sure if python could be used in
place of Assembly (or machine) Language, addressing programming needs
from the lowest to the highest level. Perhaps your notes answer my
doubts. Would like to know more.

For example, like Deepmind's Alpha Code AI, writing codes as per
requirements, research is getting there.
So I would like to develop an understanding of programming from the
lowest level to the highest level. The way programming is approached
in textbooks doesn't suit me. I can't have the flexibility to use
programming like a cobweb or a network, jumping from lowest level to
the highest level according to my need.

I read that micropython is written in c. So it is just like
circumlocuting to the same point from where it began.

So confusing!

Hope that some confusions shall be set aside in your subsequent posts.

You also said, "... debian-gcc maintainers maintain the gcc package
for Debian, they are not responsible for teaching people C or C++ ..."

I didn't expect them to teach, but only to share their insights and
information. In contrast, the debian-python group readily shared
information with me on python.

Best wishes,
Rajib




To: debian-user 
Subject: Re: How should learning to program in c++ be approached,
if learning objectives are sought to be customised?
From: IL Ka 
Date: Mon, 30 May 2022 16:34:33 +0300
Message-id: <[🔎]
CAHv=rm2ykzdjozjsqpc7gvjmdry1o6-xranxvcdgw_cqt--...@mail.gmail.com>
In-reply-to: <[🔎]
caeg4czwmot23cvnbg_rrag0gbwciot-up2v117tzg+knf2c...@mail.gmail.com>
References: <[🔎]
caeg4czwmot23cvnbg_rrag0gbwciot-up2v117tzg+knf2c...@mail.gmail.com>

Hello,
 [   ...   snip   ...   ]

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[rhkramer]

On Monday, May 30, 2022 08:56:56 AM Susmita/Rajib wrote:
> Assuming that OO is an abbreviation of Object Oriented, your email
> whets appetite but doesn't quench it. I would have definitely been
> helped by answers to my specific queries.

I don't know if you will help this very much, but I'll point out that there is 
a group / mailing list (s...@lists.isocpp.org) which seems to focus on 
developing materials (and methods, iiuc) of teaching C++.

It is a low traffic group, and they might not be interested in answering 
specific 
questions from a learner, but (1) they might be (or somebody on the list might 
be -- or point you to one or more other lists, and/or (2) they might be 
interested in your feedback on your experiences as you try to learn C++.

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Emanuel Berg]

Susmita/Rajib wrote:

> I have been on and off my idea to self-learn
> c++ programming.

Just do it ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[IL Ka]

Hello,


>  I have tried a couple of times, but debian-gcc team didn't
> respond to my earlier queries (but I shall post a copy of this one
> there too, just in case).


debian-gcc maintainers maintain the gcc package for Debian, they are not
responsible
for teaching people C or C++.

I suggest you start with Python: this language is very easy, there are lots
of books, videos and free courses
(coursera etc) and there is even MicroPython for microcontrollers.

If you really want to learn C, read "C in a nutshell" by O'reilly.
The book with a cow on the cover.

C++ would be much easier to learn once you understand C.
For C++ you can read "C++ programming language" by B. Stroustrup.

But C++ is hard, really.


> It would have been great, had a programming language been developed
> that could address both the lowest microprocessor(machine)-level to
> the most advanced user level programming, reading, comprehension and
> application. Perhaps, AI shall fulfil this need.
>
>
Python should be your choice!


(2)   object library resources, references, explanations, et al
>
For C++ you can use https://www.cplusplus.com/reference/ as reference
https://en.cppreference.com/w/ is also good, but for advanced usage


> (3)   Whether Eclipse could be used for c++
>
Yes. Also, Emacs, CLion or any other editor



> (4)   Whether Device Drivers and other lower-level programs could be
> designed with c++, like they are done in c or assembly level languages
> (I am aware that KDE was written in c++, but ...).
>

Linux drivers are written in C, but technically you can mix languages: use
C++ and link it against C.



> (5)   Whether optimisation tools like valgrind and gdb are available
> for c++ also
>
Yes, sure.

Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?

[Susmita/Rajib]

Dear Team DdB,

I write Team assuming that your team runs this company De-bruin.de,
and you are the boss. A boss doesn't reply to any and every email. So
...

I had the page translated. It said, "The biggest problem with the old
website was the open display of email addresses, making it easy for
SPAM senders and other malefactors to use it. I'm currently checking
different alternatives."

Yes, open email-IDs could potentially invite spams. But then, Google
blocks most spammers and I use plain text emails and receive emails
with blocked scripts. I don't work for an intel agency or a cutting
edge software company. So there isn't an incentive for the agency that
set up Google to spy on my emails. To be specific to your comment,
spammers are discouraged if their emails aren't responded to.

Earlier, Debian Lists used to jumble up email-IDs, but left the
practice way back.

Assuming that OO is an abbreviation of Object Oriented, your email
whets appetite but doesn't quench it. I would have definitely been
helped by answers to my specific queries.

Hope that I shall not be disheartened.

Best wishes,
Rajib



To: debian-user@lists.debian.org
Subject: Re: How should learning to program in c++ be approached,
if learning objectives are sought to be customised?
From: DdB 
Date: Mon, 30 May 2022 12:07:17 +0200
Message-id: <[🔎]
5e885eae-e1f8-0936-43c3-c15971bad...@potentially-spam.de-bruyn.de>
In-reply-to: <[🔎]
caeg4czwmot23cvnbg_rrag0gbwciot-up2v117tzg+knf2c...@mail.gmail.com>
References: <[🔎]
caeg4czwmot23cvnbg_rrag0gbwciot-up2v117tzg+knf2c...@mail.gmail.com>

Hello,
[   ...   snip   ...   ]
DdB