Re: [Nano-devel] Different keybindings behaviour when reading from a pipe - is this expected? -- No

[Enrico Mioso]

Well, sorry... maybe I am not able to explain myself as I should or to 
understand your reply. Sorry in that case.
I'll stil lretry as I would like to learn new things! :)

To sumarise: let's copy a snapshot of my /proc/interrupts file to /tmp, to get 
a regular file:
Script started on 2019-03-12 14:45:36+01:00 [TERM="linux" TTY="/dev/tty3" COLUMNS="128" 
LINES="48"]
address@hidden ~]$ file -k /tmp/interrupts
/tmp/interrupts: ASCII text\012- 
address@hidden ~]$ cat /tmp/interrupts
           CPU0       CPU1
  0:     325249          0   IO-APIC   2-edge      timer
  1:         55          0   IO-APIC   1-edge      i8042
  8:          1          0   IO-APIC   8-edge      rtc0
  9:          0        207   IO-APIC   9-fasteoi   acpi
 12:          0          2   IO-APIC  12-edge      i8042
 14:      45626          0   IO-APIC  14-edge      pata_sch
 15:          0          0   IO-APIC  15-edge      pata_sch
 17:          0          0   IO-APIC  17-fasteoi   ath9k
 18:          0        152   IO-APIC  18-fasteoi   uhci_hcd:usb4
 19:      10642          0   IO-APIC  19-fasteoi   ehci_hcd:usb1
 20:          0      29187   IO-APIC  20-fasteoi   uhci_hcd:usb2
 21:          0          0   IO-APIC  21-fasteoi   uhci_hcd:usb3
 23:          0        169   IO-APIC  23-fasteoi   snd_hda_intel:card0
 24:          0     593384   PCI-MSI 1572864-edge      enp3s0
NMI:          0          0   Non-maskable interrupts
LOC:     281200     491467   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
IWI:          0          1   IRQ work interrupts
RTR:          0          0   APIC ICR read retries
RES:      11066      16586   Rescheduling interrupts
CAL:        733        934   Function call interrupts
TLB:          6         18   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:          7          7   Machine check polls
ERR:          0
MIS:          0
PIN:          0          0   Posted-interrupt notification event
NPI:          0          0   Nested posted-interrupt event
PIW:          0          0   Posted-interrupt wakeup event
address@hidden ~]$

now:
$ cat /tmp/interrupts | nano -
Takes me to the content of the file, last line.
Now, ctrl+home and ctrl+end won't allow me to move at the first line.
Suppose I move to the line 1:
           CPU0       CPU1

Pressing ctrl+home takes the cursor at the beginning of that line, while 
pressing ctrl+end takes it to the end of that line:
ctrl+home:

<cursor>   CPU0       CPU1

Nano output due to "const":
[ line 1/34 (2%), col 1/34 (2%), char 0/1782 (0%) ]

ctrl+end:
           CPU0       CPU1       <cursor>

nano says:
[ line 1/34 (2%), col 34/34 (100%), char 33/1782 (1%) ]

with
nano /tmp/interrupts

I am taken at the end of the file, because I was there on a previous invocation 
I think.
BTW nano warns me: [ File '/tmp/interrupts' is unwritable ]

ctrl+home:
<cursor>   CPU0       CPU1

[ line 1/34 (2%), col 1/34 (2%), char 0/1782 (0%) ]

ctrl+end:

(empty line)

[ line 34/34 (100%), col 1/1 (100%), char 1782/1782 (100%) ]

But, I love nano as it is even now. :)

another interesting case, which may come directly from a programming mistake I 
am making here: I hacked up a very small script to transfer files to my iPhone.

#!/bin/sh

ls -1 |
while read filename; do
nano "$filename"
done

Here I invoke nano for each file, but I am using nano as a placeholder here: in the 
"final" version of the script, another script will be invoked.
I know I can use for, but I used this since I am able to handle filenames with 
spaces.

When I do this, nano complains:
Too many errors from stdin                              [ Read 1 line ]

(yeah, the file is only 1 line in this case).

thanks a lot for your great work, and program. and for the kindness and 
patience: invaluable things.
Sorry if I am getting something wrong, conceptually.

Enrico

On Tue, 5 Mar 2019, Benno Schulenberg wrote:

> Date: Tue, 5 Mar 2019 19:25:23
> From: Benno Schulenberg <address@hidden>
> To: Nano <address@hidden>
> Cc: Enrico Mioso <address@hidden>
> Subject: Re: [Nano-devel] Different keybindings behaviour when reading from a
>     pipe - is this expected? -- No
>
>
> Hello Enrico,
>
> Op 05-03-19 om 18:51 schreef Enrico Mioso:
> > I observed the fact that when invoking nano like:
> > cat /proc/interrupts | nano -
> >
> > pressing ctrl+end / ctrl+home won't take me at the end and beginning of the file
> > respectively, as it happens when invoking nano like
> > nano /proc/interrupts
>
> Ctrl+Home and Ctrl+End work fine for me in both invocation methods.
>
> The difference between the two is that when letting nano read from
> standard input, the cursor will be placed at the end of the buffer,
> at the end of the text that was "sucked in" through the pipe, whereas
> when invoking nano on a file, the cursor will be placed on the first
> line (when you don't use position history or haven't visited the file
> before).
>
> Maybe switching on line numbers (briefly) will give you a sense of
> where you are in the buffer?
>
> Benno