Linking on Solaris x86
Hello All, It seems that linking for some compile-time and also run-time libraries for mc on Solaris x86 is not being done properly by configure. The first problem I noticed was: compilation of man2help failed: libglib-2.0 not found next, mc would not run without setting LD_LIBRARY_PATH, which when set to point to the X libs and the location of your Glib implementation, everything was OK. Since besides that this would be improper use of LD_LIBRARY_PATH and also that it creates a hurdle for people installing mc on Solaris, Can I please request that someone with more experience (than me!!) in hacking the configure script look at this or tell me how I might be able to help fix the problem. What I did on one system to repair the problem: (believe me, I don't mean to imply that this is _the_ way to fix it, it's just how I got around it quickly) edited mc-4.6.0-pre3/src/Makefile added dirctory containing glib implementation as last argument to CFLAGS: CFLAGS = -g -O2 -Wall -L/usr/local/lib so man2help compilation succeeded. and for runtime linking appended X-libs directory and Glib-2.0 directory to LDFLAGS: LDFLAGS = -R/usr/local/lib -R/usr/openwin/lib (which origonally was empty) On this system I'm using Sun's Xserver, but on a system implementing XFree86 the runtime link directory would be something like -R/usr/X11/lib the configure log and Makefiles can be seen here: (just point your web browser to:) ftp://208.45.73.59/pub/mc/Config.log(./configure Config.log) ftp://208.45.73.59/pub/mc/Makefile.edited ftp://208.45.73.59/pub/mc/Makefile.orig ftp://208.45.73.59/pub/mc/config.log (excerpt) let me know if I can be of any help btw, this has (in my experience?!?) been true with all versions of mc. I allways just put a wrapper on mc for the linking. Tribhuvan ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: title refreshing (xtt) and the 4.6.0 release
Well enough on that one then - I thought it a liitle out of preportion (for such a minor feature). I'ts just when using mc on a production machine without a fancy PS1 setting the dangling title was basically sloppy. Two or three lines of code near the end of main() to print (even NULL) to the title bar should close this issue. ... and people like me should probably read the TO DO's a little more frequently... Tribhuvan ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
mc.hlp.it 132K (Patch applied)
Your patch fixed more than just the Italian hlp file problem: # ls -l mc.hlp.it -rw-r--r--1 root other 131632 Jan 20 18:33 mc.hlp.it but, also regularized all of the other mc.hlp files too. Pavel Roskin wrote: Just a description of what's inside: 2851 newlines. This was the case in _all_ of the mc.hlp.* files. (I guess no solaris-x86 users ever noticed before). Now the help files' first line is: [Contents] Índice de Contenidos: the rest of the file is filled with spaces. This seems to be repaired also. See the new mc.hlp.it ftp://ftp.w-color.com/pub/mc/mc.hlp.it.gz (mc-2003-01-20-1 compiled with below patch) Pavel's patch: === --- man2hlp.c +++ man2hlp.c @@ -773,6 +773,7 @@ main (int argc, char **argv) cnode-node[p - node - 2] = 0; cnode-lname = NULL; cnode-next = NULL; + cnode-heading_level = 0; } } else node = NULL; === My request sent in private remains... ...Granted. I'm just looking around to see which server has the most free resources and installed gnu apps/libs. Tribhuvan ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: test results mc.hlp.it 156+ M
Hello guys,
Andrew V. Samoilov wrote:
Can you test attached patch? I eliminate ftell()s, it is one of the
possible bottlenecks.
--- src/man2hlp.c Wed Jan 15 16:25:46 2003
+++ src/man2hlp.c Wed Jan 15 16:34:15 2003
@@ -61,38 +61,9 @@ struct node {
Applied above patch, and though the pach may have is own merit for being
applied anyway -
the runaway mc.hlp.it still exists on my configuration. (see thread).
However, in a trial error / process of elimination approach, I swapped
out the
.../doc/it/mc.1.in (for the) .../doc/pl/mc.1.in and (though nobody in
Italy would
be satisfied with the results) the resulting mc.hlp.it did not suffer
from the same
condition. So, Could there be some flaw in ...doc/it/mc.1.in ?
Tribhuvan
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: xterm_title Test Fix (delay removed)
written! Tribhuvan(ji) ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Feature suggestion - syntax highlighting in the viewer
I love the idea - for a while, I was using emacs as the viewer to get the syntax highlighting! Actually, (not to complicate your simple (and probably quite do-able)) idea, I wonder if the range of colors could be expanded to the pallete also(am i getting greedy?) ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
test results mc.hlp.it 156+ M
I am using It will be nice to know what kind of compiler does Tribhuvan use. I'm at the moment going to test compilation with various versions of automake/gcc on solaris. Since I got the problem on both Solaris 8 9, it's probably more related to the combination of versions of the below gnu packages. The problem occurred on the two following configurations... __ Tribhuvan's configuration (hlp.it FAIL) (build inside the source tree) uname -m = i86pc uname -r = 5.9 uname -s = SunOS uname -v = Generic_112234-03 gcc (GCC) 3.2.1 GNU ld version 2.13.2 aclocal (GNU automake) 1.7.2 autoconf (GNU Autoconf) 2.57 _ Tribhuvan's configuration (hlp.it FAIL) (build inside of source tree) uname -m = i86pc uname -r = 5.8 uname -s = SunOS uname -v = Generic_108529-17 gcc (GCC) 3.2 GNU ld version 2.13 aclocal (GNU automake) 1.7 autoconf (GNU Autoconf) 2.56 _ Andrew's configuration (hlp.it PASS) (build outside of source tree) uname -m = i86pc uname -r = 5.8 uname -s = SunOS uname -v = Generic_108529-01 gcc 2.95.3 GNU Autoconf 2.53. _ Pavel's configuration: (hlp.it PASS) (build outside of source tree) uname -m = sun4m uname -r = 5.9 uname -s = SunOS uname -v = Generic_112233-01 gcc ??? GNU Autoconf 2.57 ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: test results mc.hlp.it 156+ M
Update: didn't make a difference configure/build inside/outside source tree (continuing testing...) __ Tribhuvan's configuration_1 (build inside the source tree) (hlp.it FAIL) (build outside the source tree) (hlp.it FAIL) uname -m = i86pc uname -r = 5.9 uname -s = SunOS uname -v = Generic_112234-03 gcc (GCC) 3.2.1 GNU ld version 2.13.2 aclocal (GNU automake) 1.7.2 autoconf (GNU Autoconf) 2.57 Tribhuvan's configuration_2 (build inside the source tree) (hlp.it FAIL) (build outside the source tree) (hlp.it FAIL) uname -m = i86pc uname -r = 5.8 uname -s = SunOS uname -v = Generic_108529-17 gcc (GCC) 3.2 GNU ld version 2.13 aclocal (GNU automake) 1.7 autoconf (GNU Autoconf) 2.56 _ Andrew's configuration (hlp.it PASS) (build outside of source tree) uname -m = i86pc uname -r = 5.8 uname -s = SunOS uname -v = Generic_108529-01 gcc 2.95.3 GNU Autoconf 2.53. _ Pavel's configuration: (hlp.it PASS) (build outside of source tree) uname -m = sun4m uname -r = 5.9 uname -s = SunOS uname -v = Generic_112233-01 gcc ??? GNU Autoconf 2.57 ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
mc.hlp.it 156+ M
Each time i compiled or installed mc-4.6.0-pre2 I couldn't help but notice that mc.hlp.it took forever to finish. I finally got around to looking in the source/doc and /usr/local/share/mc directories and found that the file was more than 164_MEGABYTES_HUGE. This happens when compiling unmodified source from either cvs 12-28-2002 or the pre2 (12-26-2002 ? ) source bundles. Anybody else get that? Sorry I've been pretty buzy and couldn't investigate _why_ this has happened... Tribhuvan ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Xterm title [PATCH included]
re: Thomas Zajic's latest posting patch included Could you please send me the patch or tell me where i can download it if it's posted somewhere - I'm working on Solaris compatability as well as fixed a problem in the last patch version, besides an additional feature for the xterm title... Thanks Tribhuvan loka at rcn dot com ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
xterm ttle patch v898 v2
This is a modification of a patch Tomas Stylbo sent me a couple of days
ago.
Changes:
1) cut down initial delay from 5 seconds to 1 second.
2) inserted #ifdef for SA_INTERRUPT as some platforms
don't implement that in signal.h (notably Solaris-x86)
3) changed code in store_xterm_title, see: if ( i 5 ) ...
4) added option for displaying user@host in title bar
I still have to add explicit support for NATIVE_WIN32
(ie: correct environment variables for USER and HOSTNAME)
TODO:
1) the problem on remote host is still not resolved
(ie: store and restore - the title function works fine
on remote machines, but _restoring_ old title does not.
The delay on initialization of the store_xterm_title
is fine (though it could be reduced to a fraction of a second)
but I think it should be introduced in _restore_ when
mc is exiting/cleaning up. I couldn't quite figure out how to
do that.
2) I'd like to create a dialog box for these xtra features, so
that while they are compiled in by default - they can be
switched on and off on-the-fly for buggy/cheap terminal
environments.
Question for Thomas Stylbo: what platform are you testing on?
I'm testing on Solaris 8 9 x86 w/ X11R6-4.1.0, 4.2.0,
openwindows and openwindows with XF86 porting.
Terminals: xterm, rxvt, gnome terminal for the moment
Will report back full testing results a little later
Tribhuvan
loka at rcn dot com
diff -purN:
--- mc-4.6.0-pre2/src/main.c 2002-12-26 11:38:37.0 -0500
+++ mc-4.6.0-pre2.new/src/main.c 2003-01-06 06:31:17.077067000 -0500
@@ -30,7 +30,6 @@
#include stdlib.h
#include string.h
#include sys/types.h
-
#include sys/stat.h
#ifdef HAVE_UNISTD_H
@@ -296,6 +295,10 @@ char *mc_home;
char cmd_buf[512];
+/* logname@hostname for xterm_title */
+int xterm_title_who_flag = 1;
+unsigned char *who_xterm_title = NULL;
+
WPanel *
get_current_panel (void)
{
@@ -1839,17 +1842,39 @@ midnight_callback (struct Dlg_head *h, i
void
update_xterm_title_path (void)
{
-unsigned char *p, *s;
-
-if (xterm_flag xterm_title) {
- p = s = g_strdup (strip_home_and_password (cpanel-cwd));
- do {
- if (*s = 32)
- *s = '?';
- } while (*++s);
- fprintf (stdout, \33]0;mc - %s\7, p);
- fflush (stdout);
- g_free (p);
+if ( !xterm_title_who_flag ) {
+ /* without logname@hostname */
+unsigned char *p, *s;
+
+ if (xterm_flag xterm_title) {
+ p = s = g_strdup (strip_home_and_password (cpanel-cwd));
+ do {
+ if (*s = 32)
+ *s = '?';
+ } while (*++s);
+ fprintf (stdout, \33]0;mc - %s\7, p);
+ g_free (p);
+ fflush (stdout);
+ }
+} else {
+ /* with logname@hostname */
+unsigned char *p, *s, *w;
+ unsigned char o[255];
+
+ if (xterm_flag xterm_title) {
+ w = who_xterm_title;
+ p = s = g_strdup (strip_home_and_password (cpanel-cwd));
+ do {
+ if (*s = 32)
+ *s = '?';
+ } while (*++s);
+ sprintf (o, %s %s,w , p);
+ fprintf (stdout, \33]0;%s\7, o);
+ g_free (p);
+ g_free (w);
+ g_free (o);
+ fflush (stdout);
+ }
}
}
@@ -2406,11 +2431,120 @@ compatibility_move_mc_files (void)
}
#endif/* NATIVE_WIN32 */
+/* Retrieve and store xterm title */
+
+static void
+xterm_sig_alrm_h (int sig) {
+/* Do nothing.
+ * The only purpose of this signal is to interrupt the
+ * read system call in xterm_read_title(). */
+}
+
+static char *
+store_xterm_title (void)
+{
+static unsigned char title[256];
+struct sigaction sa;
+int cnt;
+char *cmd = \033[21t;
+int e;
+int tty;
+
+if ((tty = open(/dev/tty, O_RDWR | O_NOCTTY)) == -1) {
+ return (NULL);
+}
+/* Make sure we will not be blocked infinitely. */
+sa.sa_handler = xterm_sig_alrm_h;
+# ifdef SA_INTERRUPT
+sa.sa_flags = SA_INTERRUPT | SA_RESETHAND;
+# else
+sa.sa_flags = 0;
+siginterrupt(SIGALRM, 1);
+# endif
+
+sigaction(SIGALRM, sa, NULL);
+alarm(1);
+
+/* Write the request for window title. */
+e = strlen(cmd);
+while ((cnt = write(tty, cmd, e)) 0) {
+e -= cnt;
+cmd += cnt;
+}
+if (cnt == -1) {
+close(tty);
+return (NULL);
+}
+else {
+/* Read the response. */
+int i = 0;
+char ch;
+int seen_esc = 0;
+while (i sizeof(title) read(tty, ch, 1) 0) {
+if (seen_esc == 0) {
+if (ch == '\033')
+seen_esc = 1;
+else
+continue;
+}
+if (ch == '\x9c') /* ST */
+break;
+title[i++] = ch;
+}
+close(tty);
+ if (i 5)
+ return NULL;
+ title[i-2] = '\0';
+ return title+3;
+}
+}
+
+unsigned char *
+xterm_title_get_who (void)
+{
+ static unsigned char *who, *at, *where;
+
+ if ( getenv(LOGNAME) == ) {
+if ( getenv(USER) == )
+ who = mc
Re: a solution for high and dry xterm_title
Tomas Styblo wrote Personally I think that relying on the title reporting ability is too error prone. From the point of view of the user the easiest way to restore the title is to simply generate it in the PS1 variable as a part of the command prompt. I understand what you're thinking, but I think for average users without a firm grasp on even shell programming the overhead may just be a bit much (save for the learning experience). I like the xterm_title feature and have written an enhancement for it (for next posting), but maybe the restore feature can just be automatically turned off if we know a cheap/buggy terminal is running mc. Probably the safest thing to do is keep the switch handy to turn the feature on/off via one of the dialog windows. I use a TERMINALS environment variable for a number of settings. export TERMINALS='xterm rxvt dtterm' if [` echo $TERMINALS | grep $TERM`] then An array in the source code could contain a names of safe terminals, then a getenv($TERM) could determine if $TERM is a safe one to do the title refresh on exit -unless someone's spoofing... What else can you do in a polski fiiat? Let them pass you... In the meantime, I'm still working on the last patch - Solaris x86 uses SA_RESTART in sys/signal.h rather than SA_INTERRUPT. There's an #ifdef SA_RESTART earlier in the code I'm inserting into the refresh function to get around SA_INTERRUPT but it just hangs indefinetely without so far Tribhuvan ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
xterm_title patch 898
Adam Byrtek 'alpha' wrote: It was recently discussed on this list, and I've made a patch to store and restore old title: https://savannah.gnu.org/patch/?func=detailpatchpatch_id=898group_id=3521 I inserted the code as per above patch on 4.6.pre2 and tested: rxvt - ok on localhost: no-restore on remote host gnome-terminal - same as rxvt dtterm - title changes but old_xterm_title goes to stdout (comand line in mc) and causes unpredictable bhvr this is from the store_xterm_title function (this is on localhost, so didn't bother testing on remote) xterm - ok on localhost but same problem as dtterm when xterm on remote host so I see two difficulties: 1) get same behavior on remote host as localhost 2) stop the old_xterm_title from printing to the command line in dtterm (localhost) xterm (remote) in functiom store_xterm_title(): instead of printf(\e[21t); and then later return title+3; is there a way to concatinate the e\[21t] and title+3 to avoid a the double-return? I hope I'm not tooo far off... Tribhuvan ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
