Looks like there are two things that concern you. Firstly, how bash tab expansion appears to work (the ls, etc. commands executed when you hit the tab key) on your system. Secondly, the "bash: unexpected EOF while looking for matching `)'bash: syntax error: unexpected end of file" messages generated when a particular tab expansion fails.
Is that second issue generated by hitting tab at the end of the command: ls -1d root_170430_g0n*.d ? If so, perhaps there's something unusual with the items that match the pattern "root_170430_g0n*.d*" that results in the error ... Regarding your diagnosis: > 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. Before declaring bug / broken package / attack, it might be an idea to see whether the issue is reproducible, and under what circumstances. Note, tab expansion can be modified (see, for example, http://www.linuxjournal.com/content/more-using-bash-complete-command). -----Original Message----- From: Miroslav Rovis [mailto:miro.ro...@croatiafidelis.hr] Sent: Friday, May 05, 2017 01:02 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance Hi Bobby! Pls. see also: Tab (no exec) triggers script on Bash on grsec admin https://forums.grsecurity.net/viewtopic.php?f=3&t=4700 as well as the other email that I sent some 7 or so hours ago. NOTE: if I'm away, it's because I'm a little worried... I'm afraid my system may be vulnerable because of these issues. Patience pls. (no more but only my sig in bottom) On 170504-21:15-0400, Bobby Kent wrote: > 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.ro...@croatiafidelis.hr] > Sent: Tuesday, May 02, 2017 10:13 > To: gentoo-user@lists.gentoo.org > 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/gi > > t- > > 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 > > > Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr
