NevemTeve blogja

mc, TERM=linux, gpm, jajjanyám

 ( NevemTeve | 2014. május 21., szerda - 15:28 )

20170611
Úgy nézem, akkor lép fel, ha TERM=putty-256color... Na most jön a --without-gpm-mouse
Szerk: téves riasztás, volt a gépemen egy ősrégi /usr/bin/mc[edit], az indult el tévedésből ($EDITOR volt ráálítva)

20170609
Na ez miez (végtelen sok ismétlődéssel az 'user-log'-ban, Debian8/mc-4.8.17):

Jun  7 11:46:52 z-pc mcedit: Warning: closing connection
Jun  7 11:46:52 z-pc mcedit: *** info
Jun  7 11:46:52 z-pc mcedit: Warning: closing connection

20160927.1202

find -- ez most kiszúrás, vagy csak szórakozik velem?

 ( NevemTeve | 2014. május 7., szerda - 17:00 )

find . -name Makefile -exec echo {}.extension \;

Ez a find-parancs AIX5.3-on a következőt generálja:

{}.extension
{}.extension
{}.extension

Na ez most kiszúrás, vagy csak szórakozik velem?

20140508.0508: Köszönöm a hozzászólásokat, azóta működik a kerülő-módszerrel ( vagyis átirányítással egy 'while read FILENAME; do'-ba)

git=szenya

 ( NevemTeve | 2014. április 29., kedd - 17:47 )

Vagy hasonló. Például Harry Potter ellenszenves tanárát 'greasy git'-ként emlegetik. Ennél nagyobb gondom, hogy a git-1.9.2 ellenáll a fordításnak az egyik AIX-os gépemen. A következő apróságok örvendeztettek meg:

1. a make distclean törli a configure-t. Szerintem inkább a Makefile-t kellene törölnie, de hát ahány ház, annyi szokás; megoldjuk:
sed_repl 's/^ \$(RM) configure/ # $(RM) configure/' Makefile

2. Nem használja a libtool-t. Megoldás:
make ... QUIET_LINK='aix-libtool --mode=link ' ...

libtool újabb kalandjai...

 ( NevemTeve | 2014. április 4., péntek - 11:36 )

Nem fordul a gettext... már számtalanszor lefordult, de most nem, megpusztult a configure a libiconv keresésénél...
És végül kiderült, hogy ki a hibás. Hát én, természetesen. Nem tudtam, hogy a configure script a libtool *.la fájlját (esetünkben a /usr/local/lib/libiconv.la-t) shell-scriptként akarja feldolgozni!
Vagyis abban nem lehet ám akármi, csak változó=érték hozzárendelések, és #kettőskereszttel bevezetett megjegyzések... Persze ennek egy jó kis kapkodás közben kellett előkerülnie, semmiképp sem valami békés pillanatban...

sshd: key_parse_private2: missing begin marker

 ( NevemTeve | 2014. március 26., szerda - 16:31 )

Ez mi ez?

debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker

Egyelőre annyit látok, hogy van egy authfile.c és abban egy key_parse_private2 függvény.

20140326.1643 Mintha az lenne, hogy a [/usr/local]/etc/ssh-beli ssh_host_*_key fájlokban a fejléc/lábléc lenne hibás:

ez van:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

ezt várja:

-----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----

LC_CTYPE: ISO-8859-2 vagy ISO8859-2

 ( NevemTeve | 2014. március 25., kedd - 12:07 )

Újabb nagy diadala a szabványoknak és az együttműködésnek: egyik unix így szereti, a másik meg amúgy... Ha én meg ssh-ból megyek egyikből a másikba (vö: SendEnv és AcceptEnv), akkor vagy jó lesz a másikfajta, vagy nem. Hirtelen ennyit tudok javasolni megoldásként:

http://web.axelero.hu/lzsiga/ekezet.html#Q0094

20140127.1003: És ehhez egy kis kiegészítés

http://web.axelero.hu/lzsiga/ekezet.html#Q0096

Oracle TCP_KEEPALIVE nélkül?

 ( NevemTeve | 2014. március 14., péntek - 11:50 )

2017.02.27. 10:46
Említsük meg, hogy AIX-on a könnyen googlizható nevű "no" segédprogrammal lehet a TCP_KEEPALIVE időzítését hangolni.

$ /usr/sbin/no -a | grep keep
                ndpt_keep = 120
              tcp_keepcnt = 8
             tcp_keepidle = 14400 # = 2 óra
             tcp_keepinit = 150
            tcp_keepintvl = 150
# /usr/sbin/no -o tcp_keepidle=120 #  = 60 sec (félmásodperces egységben)

2014.03.14. 15:53
Továbbá szerveroldalon: sqlnet.ora-ban sqlnet.expire_time=<perc>

Szemaforok -- van választék

 ( NevemTeve | 2014. március 3., hétfő - 20:04 )

A múltkori eset után picit utánaolvastam a szemaforoknak, és egy kis táblázatot alkottam: itt látható..

Már írtam is hozzá egy kis kiegészítést: a SsystemV IPC-nek szerencsés tulajdonsága, hogy ha használjuk a SEM_UNDO opciót, akkor egy váratlan leállás sem tudja zárolva hagyni a szemafort, ami viszont megtörténhet a POSIX-os szemaforral.

Bepörög az Apache az imagick-tól

 ( NevemTeve | 2014. február 26., szerda - 18:29 )

Ez most csak egy emlékeztető magamnak, hogy ismét akadt egy kis nyomoznivaló...

Komponensek:

AIX 6.1 (oslevel 6100-09)
Apache httpd-2.4.7
PHP-5.4.24
ImageMagick-6.8.8-4
imagick-3.1.2

Hibajelenség:

A 'phpinfo()' elég a hiba bemutatásához, de csak Apache-on át, standalone-ban jó.
Úgyszintén jó, ha httpd -X paranccsal futtatom.
Akkor is, ha nincs a php.ini-ben az extension=imagick.so.

új Apache, új gondok...

 ( NevemTeve | 2014. február 6., csütörtök - 11:37 )

Komponensek:

AIX-5.2
httpd-2.4.7
apr-1.5.0
apr-util-1.5.3

Problémás rész:

[code]/usr/local/src/httpd-2.4.7/srclib/apr/libtool --silent --mode=link \
gcc -pthread -mtune=native -maix32 -std=c99 \
-Wl,-brtl -L/usr/local/lib -lcpotlas -Wl,-brtl,-brtllib -lrtl \
-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -Wl,-brtl \
-o mod_cache_socache.la \
-Wl,-bI:/usr/local/src/httpd-2.4.7/server/httpd.exp \
/usr/local/src/httpd-2.4.7/srclib/apr-util/libaprutil-1.la \

OpenSsl reloaded

 ( NevemTeve | 2014. január 30., csütörtök - 18:06 )

openssl-ék szerint az 1.0.1 az már nem olyan, mint a 0.9.8, hogy minden alverzió inkompatibilisnek számít. Nem, itt már az 1.0.1 kompatibilis az 1.0.0-lal.

Normálisan ilyenkor a verziószámot major+minor részre bontják, a major változása inkompatibilis fejlesztést jelent, a minor változása kompatibiliset (vagyis újrafordítás/szerkesztés nélkül használható az új) pl:

major=1.0.1g minor=(üres)
major=1.0.1 minor=g
major=1.0 minor=1
major=1.0 minor=1g
stb

gdb-vel kavarok

 ( NevemTeve | 2014. január 23., csütörtök - 14:31 )

egyik gép (linux; gdb-7.5.1) így írja ki a shared libeket:

From        To          Syms Read   Shared Object Library
0xf7fe1830  0xf7ff7c8f  Yes (*)     /lib/ld-linux.so.2
0xf7fc1a40  0xf7fc2988  Yes (*)     /lib/i686/cmov/libdl.so.2
0xf7e90a80  0xf7f8647c  Yes (*)     /lib/i686/cmov/libc.so.6

Nem rossz, de lehetne jobb: ha kiírná az adatterületeket is.

másik gép (AIX; gdb-7.3):
[code]Text Range Data Range Syms Shared Object Library
0xd052d240-0xd052da3e 0xf0828608-0xf0828730 Yes /usr/lib/libcrypt.a(shr.o)

backspace ^H vagy ^?

 ( NevemTeve | 2014. január 11., szombat - 15:43 )

De komolyan, olvtársak, hogy van az, hogy az elmúlt 40-50 év még nem volt elég ahhoz, hogy megnyugtatóan rendeződjön ez a mélységesen mély probléma?

Most ne mondjuk azt, hogy a bash/readline/mc/egyéb program tök jól kezeli mindkettőt, hanem vegyük elő a legfelhasználóbarátságtalanabb programunkat (pl dash, ksh), és nézzük meg, hogy abban működik-e a BackSpace, vagy esetleg megjelenik helyette egy ^H vagy ^? szekvencia.

Win16-os hibakeresés

 ( NevemTeve | 2014. január 9., csütörtök - 15:50 )

Valamit elronthattam, debuggolni kellene. Ahogy látszik a dolog, Assembly szinten kellene nézelődni (A function-prolog lehet rossz. Talán.)... Sajnos a jó öreg BorlandC4.5-höz tartozó TDW nem indul el. Google barátom az OpenWatcom-ot ajánlotta, annak van 16-bites fordítója és debuggere is. Kipróbáltam, tényleg van.
Sajnos megpusztul azon a ponton, amikor 'huge' pointerrel kellene matekoznia.

struct list

 ( NevemTeve | 2014. január 6., hétfő - 17:03 )

cvs-1.11.21 nem fordul AIX-5.3-on; a hiba oka: 'struct list' redefined.
Megnéztem, tényleg.
Egyrészt a cvs/src/hash.h -ban, másrészt a /usr/include/grp.h -ban van ilyen. Gratulálok a fantáziájukhoz. Eddig nem jött ki, mert az utóbbi csak a _THREAD_SAFE beállítás mellett aktíválódik.

Első ötletként keresek újabb CVS-t (nyílván új függőségekkel és inkompatibilitásokkal, természetesen).

20140106.1717: Úgy néz ki, hogy ez lett a barátunk: http://ftp.gnu.org/non-gnu/cvs/source/stable/1.11.23/

Ora64 kliens a jó öreg debian6.0.5-re

 ( NevemTeve | 2013. november 14., csütörtök - 11:37 )

Volt már nekem egy 10-es verzióm, Pro*C-vel meg Sql*Plus-sal, de lassan kellene haladni a 64-bit felé is.

Oracle-től leszedtem ezeket:

instantclient-*-linux.x64-11.2.0.4.0.zip;
*=basic,jdbc,odbc,precomp,sqlplus,tools

egyelőre ezek közül csak a basic-ba mentem bele, abból mindent, aminek tetszett a neve, telepítettem a meglévő /usr/local/OraHome_Current-be egy új lib64 mappába:

[code]
-rwxrwxr-x 1 root root 25420 Aug 24 19:30 adrci
-rw-rw-r-- 1 root root 439 Aug 24 19:30 BASIC_README
-rwxrwxr-x 1 root root 47860 Aug 24 19:30 genezi

16-bit vagy 64-bit?

 ( NevemTeve | 2013. október 26., szombat - 19:24 )

Valamilyen lelki okból a dtelnet-ből most először 64-bites verziót is csináltam. A leltöltési statisztika két hét után a következő:

source: 5
16-bit: 16
32-bit: 476
64-bit: 6

Namostan én vagyok hülye, vagy rosszul látok, vagy a felhasználóknak nem szóltak, hogy a 16-bites Windows 3.x elavult?

bash fagyik AIX-on

 ( NevemTeve | 2013. október 17., csütörtök - 9:45 )

A komponensek:
szerver: AIX 5.2, házilag fordított bash-3.2.48
kliens: Debian linux 6, házilag fordított rxvt-2.7.10

Hibajelenség reprodukálása:
1. belépés (telnet)
2. még működik (pl kiprobáljuk a stty size parancsot -- jó)
3. felnagyítjuk az ablakot
4. már nem működik (ugyanaz a parancs, mint az előbb -- nincs válasz)

Kieg:
1. ugyanez a jelenség xterm-mel
2. mindegy, milyen parancsot futtatunk, az átméretezés után mindenképp fagyás van
3. ahol én fagyást látok, ott igazából a bash végtelen ciklusban falja a CPU-t

64-bites compiler Windows-ra

 ( NevemTeve | 2013. október 7., hétfő - 16:50 )

Keresgéltem egy keveset, míg végül kiderült, hogy az 'apt-get install mingw-w64' az én barátom; most éppen ezek a komponensek vannak a gépemen:

ii  gcc-mingw32      The GNU Compiler Collection (cross compiler for MingW32 / MingW64)
ii  mingw-w64        Minimalist GNU w64 (cross) runtime
ii  mingw32-binutils Minimalist GNU win32 (cross) binutils
ii  mingw32-runtime  Minimalist GNU win32 (cross) runtime

Ilyesmik lesznek a Makefile-ban:

CC      := amd64-mingw32msvc-cc
RC      := amd64-mingw32msvc-windres
LIBS    := -lkernel32 -lws2_32

Putty -- Home/End ez mi ez?

 ( NevemTeve | 2013. szeptember 30., hétfő - 11:10 )

Van a putty-ban egy olyan, hogy Terminal/Keyboard/TheHomeAndEndKeys, lehet standard vagy rxvt.
A doksi szerint:

The Unix terminal emulator `rxvt' disagrees with the rest of the
       world about what character sequences should be sent to the server by
       the Home and End keys.

       `xterm', and other terminals, send `ESC [1~' for the Home key, and
       `ESC [4~' for the End key. `rxvt' sends `ESC [H' for the Home key
       and `ESC [Ow' for the End key.

rxvt: resize megszűnt működni

 ( NevemTeve | 2013. szeptember 25., szerda - 13:05 )

Azzal próbálkozom, hogy 'resize -s 81 25' de nincs eredmény, csak timeout.
Házilag fordított rxvt-2.7.10 -ről lenne szó.

A 'debianos'-sal meg az urxvt-vel megy.

20130925.1430 Úgy tűnik, hogy a command.c-ben a rxvt_process_window_ops függvényt kellene debuggolni. Mondjuk egy furcsaságot látni vélek:
[code]void
rxvt_process_window_ops(rxvt_t *r, const int *args, unsigned int nargs)
{
switch (args[0]) {
case 1:/* deiconify window */
case 2:/* iconify window */
case 3:/* set position (pixels) */
case 4:/* set size (pixels) */

libtool #123

 ( NevemTeve | 2013. szeptember 6., péntek - 18:16 )

Kedvenc hobby-projektjeim egyike egy libtool-kompatibilis eszköz összegányolása, persze sosincs kész, most éppen a mc-4.8.10 buktatott meg. A gond azzal függhet össze, hogy agresszíven használ convenience librarykat, és a poén kedvvért azonos nevű objekteket (lib.o) is telepít mindegyikbe.

Első lépésként a fordítás során gondosan elrejtett információt kellene láthatóvá tenni:

[code]
find . -name Makefile -exec \

putty és egér (és mc)

 ( NevemTeve | 2013. szeptember 2., hétfő - 15:58 )

Előző adásunk folytatása: most éppen az lenne jó, ha a 'putty'-t használva is menne az egerentyű.

Tesztek:

$ infocmp putty | grep 'kmous'
kmous=\E[M

rxvt ablakban:

TERM=putty mc
nem megy az egerentyű

Akkor most jöjjön az, hogy megpatcheljük a mc-4.8.10 forrását:

[code]src/mc-4.8.10# diff -u0 lib/tty/tty.cold lib/tty/tty.c
--- lib/tty/tty.cold 2013-06-25 23:29:14.000000000 +0200
+++ lib/tty/tty.c 2013-09-02 16:50:06.000000000 +0200
@@ -107,3 +107,8 @@
- || strncmp (termvalue, "konsole", 7) == 0

rxvt és egérgörgő (és mc)

 ( NevemTeve | 2013. augusztus 29., csütörtök - 11:25 )

Szóval, a kérdés: miért nem megy az rxvt-ben futtatott mc-ben az egérgörgő?

Haladjunk lépésenként:

1. xterm-ben, Eterm-ben megy a görgő

2. a TERM változó nem számít

3. nem arról van szó, hogy az egér általában nem megy; bal klikk, jobb klikk működik

4. segédprogrammal ellenőrizve (shkeys -mouse) azt látjuk, hogy a görgőtekerés küld be ESC-szekvenciát

4. mc verzió: 4.8.10, forrásból fordítva, linux-on; 4.7.5.5, forrásból fordítva, AIX-en; 4.7.0.9, Debian package-ből, linuxon

terminal: scrolling region

 ( NevemTeve | 2013. augusztus 20., kedd - 17:20 )

Amíg mérlegelik, hogy lesz-e tűzijáték, gyorsan becsépeltem pár szót a scrolling region mibenlétéről: Itten van