RE: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

[Bobby Kent]

Hi Miroslav,

Attempting to reproduce third issue:

# mkdir wibble1_1
# mkdir wibble2_1
# mkdir wibble3_1
# mkdir wibble4_1
# mkdir wibble5_1
# for d in wibble*_1 ; do mkdir $d/wobble ; done
# ls -1d wibble*_1
wibble1_1
wibble2_1
wibble3_1
wibble4_1
wibble5_1

Then hit tab after positioning cursor after the / below:
# for i in $(ls -1d wibble*_1/) ; do echo $i ; done

And the results are an attempt to autocomplete:
wibble1_1// wibble2_1// wibble3_1// wibble4_1// wibble5_1//

Perhaps the test oversimplified the issue, though maybe you could provide
the simplest way to reproduce what you see.

Thanks.


-----Original Message-----
From: Miroslav Rovis [mailto:miro.rovis@××××××××××××××.hr] 
Sent: Tuesday, May 02, 2017 10:13
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

I've received one reply, and thanks again, but I had better remove the
gzip-"inconsistency" related bloat from my own previous email... I need the
previous text to make the remaining three important
parts/issues/inconsistencies clearer and easier to check, and reply to, any
of the three.

I will also reorder my quotes to get them easier to skip or skip to, since
they are separate issues/inconsistencies.

On 170501-18:17+0200, Miroslav Rovis wrote:
...
First issue
===========
(All first issue-related text have been removed here from all quotes from my
previous message) ...

Second issue
============
> Another part is actually on Wireshark mailing list. Pls. see:
>
> Filtering on (negated) frame.time_relative filters out wrong
> frame.number
> https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html
> as well as my study at:
> https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-
> devuan-mail-4.php
That page has just been updated with clearer instructions.

> (and the previous ones there, but I gave the last as it is
> simplest/fastest to check)
>
> There is information that any advanced reader can easily provide by
> retracing some of my steps there, and which would clear some uncertainties
here.
...
> ... That's a serious bug or a
> serious malfunction in my Gentoo, the latter being most likely...
>
> And if it is the latter, it can only be one or the other way. One: the
> cause is in some Gentoo packge. Two: it is an attack by some unknown
means.
>
> (
> If Air-Gapped is some info, I did try and editcap (and the whole
> Wireshark) behave in the same wrong way in my Air-Gapped too.
> ...
> )
>


Third issue
==========

The text it too much because the command line in which bash throw strange
error is a long for loop. The main point is marked with short new text
below.
> This is one of a series of commands that I used to check one of the
> backups, in three different instances of tar-gzip'd archive I checked
> (such as the /root directory tar-gzip'd today), and which showed
> faultless upon decompression in all the three instances, despite the
> three instances of tar-gzip'd archives not being identical (as their
SHA256 sums show):
>
> # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed
> 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed
> 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file
> in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >>
> ../$sum ; fi; done ; cd - ; done ;
>
> Now if I just place the cursor, by moving with Alt-F (skipping "words")
and Ctrl-F (skipping  1 char) to just after:
>
> "for i in $(ls -1d root_170430_g0n*.d/" in that command,
>
> and if I then hit Tab for completion on the experssion there, I get
> (and I'm sorry for the mess, but that's what I get):
>
> g0n ~ # for i in $(ls -1d root_170430_g0n*.dbash: unexpected EOF while
> looking for matching `)'bash: syntax error: unexpected end of
> file//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in
> $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >>
> ../$sum ; fi; done ; cd - ; done ;
>
> NOTE (at proofreading time): rechecked, I do get that same behavior
> the day after (wrote most of this yesterday, still to send this morning).
>
> [[
> NOTE (before delayed sending): In fact, it is only this clone that
> exibits the above Bash malfunctioning. I just checked the same for
> loop command (some six paragraphs above) in my Air-Gapped master [1]
> (never any internet it sees,
The [1] is important for understanding, especially this Bash issue in my
Gentoo instance.
Because in my Air-Gapped Gentoo instance that issue does not show at all.
> longer workaround/detailed checking before updating it with stuff from
> internet, sneakernet or optical media), and it is just fine. That
> line, simply gave what it should:
>
> # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed
's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed
's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in
$(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum
; fi; done ; cd - ; done 
> root_170430_g0n_1.d// root_170430_g0n_2.d// root_170430_g0n.d//
> # [[and the same command line was back here]]
>
> under exact same conditions/circumstances as the clone of my
> Air-Gapped. And it's similar with some other completion issues: they
> seem non-existent in my Air-Gapped.
> ]]

This is the main point (in my clone that I use for online):
> IOW, first, Bash sullied the entire line, which is not very
> considerate of Her, and second that's not some usual error. Just for
clarity, it wrote this:
>
The error:
> bash: unexpected EOF while looking for matching `)'bash: syntax error:
> unexpected end of file
>
> (and it wrote it by overwriting, which I never used to see in Bash)
  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^
  |  |  |  |  |  |  |  |  |  |  |  |
Anyone else such behavior as well?

>
> What's going on there?... Ah... Importantly:
>
> do any of you other users get some erratic unusual behavior like this with
Bash?
>
> Of course, I can move to the start of the line with Ctrl-A and then issue
> Ctrl-K to clear and capture to the entire line and then issue Ctrl-Y to
paste
> it back, and no disorderly message remains, but Bash isn't behaving...
>
...
> ... if the reader has this bash version installed:
> $ bash --version
> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $
> they might be able to reproduce such kind of misbehavior.
Else it's only in my Gentoo instance (and only the for-online clone, not
in my Air-Gapped Gentoo instance).

Fourth issue
============
> And finally, and this is what eix throws on any package that I would
check:
>
> g0n ~ # eix memtest86+
> * sys-apps/memtest86
>      Available versions:  4.3.7 (~)4.3.7-r1 {serial}
>      Homepage:            http://www.memtest86.com/
>      Description:         A stand alone memory test for x86 computers
...
>
> Found 2 matches
> Received SIGSEGV - you probably found a bug in eix.
> Please proceed with the following few instructions and help us find the
bug:
>  * install gdb (sys-devel/gdb)
>  * reemerge eix with FEATURES="nostrip" CXXFLAGS="-g -ggdb3" LDFLAGS=""
>  * enter gdb with "gdb --args eix your_arguments_for_eix"
>  * type "run" and wait for the segfault to happen
>  * type "bt" to get a backtrace (this helps us a lot)
>  * post a bugreport and be sure to include the output from gdb.
  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  
  |  |  |  |  |  |  |  |  |  |  |  | 
Anyone else gets this too?

...
> ---
> [1] My methods are still these:
> Air-Gapped Gentoo Install, Tentative
> https://forums.gentoo.org/viewtopic-t-987268.html
>
> and
>
> Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
> https://forums.gentoo.org/viewtopic-t-999436.html#7613044
>

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr