Hello Greg!
On 1/16/25 21:31, Greg Wooledge wrote:
> On Thu, Jan 16, 2025 at 20:27:17 +, Johannes Krottmayer wrote:
>> $ g++ -lvulkan -o test test.cpp
>
> If I recall correctly, the library options need to be *after* the object
> files that use them. Thus:
>
> g++ -o test test.cpp -lvu
On Thu, Jan 16, 2025 at 20:27:17 +, Johannes Krottmayer wrote:
> $ g++ -lvulkan -o test test.cpp
If I recall correctly, the library options need to be *after* the object
files that use them. Thus:
g++ -o test test.cpp -lvulkan
Hello,
I have encountered an issue when trying to compile and link against
libvulkan with the GNU C++ compiler and GNU ld. Get 'undefined
reference' errors on all library calls with:
$ g++ -lvulkan -o test test.cpp
The related package is installed on my system (also
the developme
On Wed, Dec 18, 2024 at 10:51 AM Franco Martelli wrote:
>
> On 17/12/24 at 22:09, Jeffrey Walton wrote:
> > [...]
> > There may be one logic error in the code -- if you insert one item,
> > then you may double free the node because you free 'p' and then you
> > free 'last'.
> >
> > I would rewrite
rks, Valgrind says 0 errors and: "All heap blocks
were freed -- no leaks are possible".
GCC gives me a warning, so I've to remove the "const" modifier in the
"for loop":
$ gcc -Wall e09-01.c
e09-01.c: In function ‘dealloc’:
e09-01.c:57:47: warning: passing a
On Wed, Dec 18, 2024 at 10:45:43AM +, Kevin Chadwick wrote:
> 18 Dec 2024 05:03:12 to...@tuxteam.de:
>
> > I'm all for concise code, but I usually revert some things in a second
> > pass when they seem to hurt clarity. After all, you write your code for
> > other people to read it.
>
> As you
18 Dec 2024 05:03:12 to...@tuxteam.de:
> I'm all for concise code, but I usually revert some things in a second
> pass when they seem to hurt clarity. After all, you write your code for
> other people to read it.
As you wrote the code then uness that second pass is weeks or months later then
cla
Franco Martelli writes:
> Peter A. Darnell, Philip E. Margolis - "C A Software Engineering Approach":
>
> https://www.google.it/books/edition/_/1nsS5q9aZOUC?hl=it&gbpv=0
>
> Do you have it too? It's pretty old, with some typo, but it looks to
> me good.
On Tue, Dec 17, 2024 at 04:18:17PM -0500, Greg Wooledge wrote:
> On Tue, Dec 17, 2024 at 16:09:09 -0500, Jeffrey Walton wrote:
> > I would rewrite the cleanup code like so:
> >
> > void dealloc()
> > {
> > DIGIT *next, *p = head;
> > while( p )
> > next = p->nex
Hello :)
Le 17/12/2024 à 12:20, Anssi Saari a écrit :
Franco Martelli writes:
I'd prefer a mailing-list instead, once finished all the exercises,
I'd like to looking for somebody that he has my same handbook and to
ask him for exchange the exercises for comparison purpose.
Just curious, whi
On Tue, Dec 17, 2024 at 16:09:09 -0500, Jeffrey Walton wrote:
> I would rewrite the cleanup code like so:
>
> void dealloc()
> {
> DIGIT *next, *p = head;
> while( p )
> next = p->next, free( p ), p = next;
> }
The logic looks good, but I'm not a fan of thi
ree( last );
> > }
> >
> > The use of 'next' stashes away the pointer so you can free 'p' and
> > still access the next pointer.
>
> Thanks, your code works, Valgrind says 0 errors and: "All heap blocks
> were freed -- no leaks are possible&
arning, so I've to remove the "const" modifier in the
"for loop":
$ gcc -Wall e09-01.c
e09-01.c: In function ‘dealloc’:
e09-01.c:57:47: warning: passing argument 1 of ‘free’ discards ‘const’
qualifier from pointer target type [-Wdiscar
h handbook is it?
Peter A. Darnell, Philip E. Margolis - "C A Software Engineering Approach":
https://www.google.it/books/edition/_/1nsS5q9aZOUC?hl=it&gbpv=0
Do you have it too? It's pretty old, with some typo, but it looks to me
good.
--
Franco Martelli
Franco Martelli writes:
> I'd prefer a mailing-list instead, once finished all the exercises,
> I'd like to looking for somebody that he has my same handbook and to
> ask him for exchange the exercises for comparison purpose.
Just curious, which handbook is it?
Franco Martelli wrote:
...
> I'd prefer a mailing-list instead, once finished all the exercises, I'd
> like to looking for somebody that he has my same handbook and to ask him
> for exchange the exercises for comparison purpose.
> Does anybody know a mailing-list fo
On 16/12/24 at 20:49, Jeffrey Walton wrote:
On Mon, Dec 16, 2024 at 2:22 PM Franco Martelli wrote:
I'm doing the exercises of a C language handbook. I'm using Valgrind to
check for memory leak since I use the malloc calls. In the past I was
used to using "valkyrie" but s
On 16/12/24 at 20:42, Michael Kjörling wrote:
On 16 Dec 2024 17:21 +0100, from martelli...@gmail.com (Franco Martelli):
Put in something to count the number of calls to malloc() and free()
respectively. Don't forget calls outside of loops.
There isn't calls to malloc() or free() outside loops.
free( last->prev );
free( last );
}
and it worked, now the output of Valgrind is:
$ valgrind --track-origins=yes --leak-check=full -s ./a.out
==114549== Memcheck, a memory error detector
==114549== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==114549
On Mon, Dec 16, 2024 at 2:22 PM Franco Martelli wrote:
>
> I'm doing the exercises of a C language handbook. I'm using Valgrind to
> check for memory leak since I use the malloc calls. In the past I was
> used to using "valkyrie" but sadly isn't available anym
On 16 Dec 2024 17:21 +0100, from martelli...@gmail.com (Franco Martelli):
>> Put in something to count the number of calls to malloc() and free()
>> respectively. Don't forget calls outside of loops.
>
> There isn't calls to malloc() or free() outside loops. What do you mean?
>From a quick re-gla
On Mon, 16 Dec 2024 16:05:26 +0100
Franco Martelli wrote:
> I'm doing the exercises of a C language handbook.
By all means do the exercises in your handbook as a learning
experience. After that, I have found very useful Roger Sessions,
Reusable Data Structures For C, Prentice Ha
On Mon, Dec 16, 2024 at 17:34:36 +0100, Franco Martelli wrote:
> > > void dealloc()
> > > {
> > > for ( const DIGIT *p = head; p->next != NULL; p = p->next )
> > > if ( p->prev != NULL )
> > > free( p->prev );
> > > free( last );
> > > }
> >
> > I think you might ha
On 16/12/24 at 16:58, Greg Wooledge wrote:
On Mon, Dec 16, 2024 at 16:05:26 +0100, Franco Martelli wrote:
void add_element( unsigned int i )
{
DIGIT *p;
/* If the first element (the head) has not been
* created, create it now.
*/
if ( head == NULL )
On 16/12/24 at 16:43, Michael Kjörling wrote:
On 16 Dec 2024 16:05 +0100, from martelli...@gmail.com (Franco Martelli):
Is there a memory leak? What it sounds strange to me is that Valgrind
reports: "total heap usage: 9 allocs, 8 frees, …" when for me the calls to
"malloc" should be 8, not 9.
On Mon, Dec 16, 2024 at 16:05:26 +0100, Franco Martelli wrote:
> void add_element( unsigned int i )
> {
> DIGIT *p;
> /* If the first element (the head) has not been
> * created, create it now.
> */
> if ( head == NULL )
> {
> head = last = (DIGIT *
On 16 Dec 2024 16:05 +0100, from martelli...@gmail.com (Franco Martelli):
> Is there a memory leak? What it sounds strange to me is that Valgrind
> reports: "total heap usage: 9 allocs, 8 frees, …" when for me the calls to
> "malloc" should be 8, not 9.
Put in something to count the number of call
Hi,
I'm doing the exercises of a C language handbook. I'm using Valgrind to
check for memory leak since I use the malloc calls. In the past I was
used to using "valkyrie" but sadly isn't available anymore for Bookworm
(does anybody know for a replacement?).
I suppos
lly start the compilation
process under screen, and I record everything using C-a H. You
might prefer termux, but well, I think I started using screen around
1990, kind of a bad habit. That's probably about when I stopped
using C-s (?).
Or even sometimes I just use script -- or even asciinema (
Marc SCHAEFER (12024-11-05):
> > It is very handy on emulated ttys too. You never had the output of
> > tcpdump / tail -f /var/log/ / make you wanted to pause to inspect
> > something?
> On slow, physical VT100 terminals, indeed, I used that over 20 years
> ago. On virtual ones they are usually to
mp / tail -f /var/log/… / make you wanted to pause to inspect
> > something?
>
> I always use `C-z` for that.
>
Yes, I suppose that works too (if in a rather different way).
--
Chris Green
Nicolas George [2024-11-05 12:11:39] wrote:
> Marc SCHAEFER (12024-11-05):
>> It could have been handy on a real tty
> It is very handy on emulated ttys too. You never had the output of
> tcpdump / tail -f /var/log/… / make you wanted to pause to inspect
> something?
I always
On Tue, Nov 05, 2024 at 12:11:39PM +0100, Nicolas George wrote:
> Marc SCHAEFER (12024-11-05):
> > It could have been handy on a real tty
>
> It is very handy on emulated ttys too. You never had the output of
> tcpdump / tail -f /var/log/… / make you wanted to pause to inspect
> something?
>
It's
> > tcpdump / tail -f /var/log/ / make you wanted to pause to inspect
> > something?
>
> On slow, physical VT100 terminals, indeed, I used that over 20 years
> ago. On virtual ones they are usually to quick to spit out nowadays.
FWIW, I still do use that on (mostly) Xterm these da
ow, physical VT100 terminals, indeed, I used that over 20 years
ago. On virtual ones they are usually to quick to spit out nowadays.
I usually relauch the command under screen C-a-h or with
> /tmp/blabla 2>&1
> Then the first time it happens to them they will search for 'linux
>
et out of the "pause" by typing C-q, after they types C-s by
> mistake.
Then the first time it happens to them they will search for “linux
terminal frozen” on the web and learn something.
> Just curious whether there is a reason why it is not disabled in .bashrc?
Changing rando
Hello,
Something funny is that on a pty you have XON/XOFF software flow control
enabled by default:
- if you type C-s (XOFF), output will be paused
- if you type C-q (XON), output will be resumed
It could have been handy on a real tty -- serial line/port -- although
when I was using
Dear,
debian Nicaragua
Best regards
Mr.Dominique Simeone
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.scri
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
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
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 troubl
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
norma
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
* 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.U
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/htm
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 sever
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 L
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.
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>~
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.ti
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 sh
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 s
t; 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
ange 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
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
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
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=
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
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?
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 lo
s 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
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 re
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
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?
--
Nicol
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 hor
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 th
> 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, yo
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
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 m
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, ko
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 s
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
abov
s 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
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
r 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,
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
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/s
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
on3.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 wasinstalle
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:
>
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
t; in dash, I get:
> > > > >
> > > > > $ foo1
> > > > > foo2
> > > > > foo3
> > > > > sh: 1: foo1: not found
> > > > > $ sh: 2: foo2: not found
> > > > > $ sh: 3: foo3: not found
> > &g
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&qu
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
instance, if I paste the following 3 lines
> > > >
> > > > foo1
> > > > foo2
> > > > foo3
> > > >
> > > > in dash, I get:
> > > >
> > > > $ foo1
> > > > foo2
> > > > foo3
> &
1
> > > foo2
> > > foo3
> > >
> > > in dash, I get:
> > >
> > > $ foo1
> > > foo2
> > > foo3
> > > sh: 1: foo1: not found
> > > $ sh: 2: foo2: not found
> > > $ sh: 3: foo3: not found
>
oo1
> > 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.
>
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.
> >
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.
> > > T
s 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.
> > > >
> &
e 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 &qu
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 occasion
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
, 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:
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
;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 s
le (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.)
>
o 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 h
) 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
1 - 100 of 2944 matches
Mail list logo
