Re: Bug with colored prompt?
If you use invisible characters in your prompt you need to tell the shell by enclosing them in \[ and \]. If you don't then it will miscalculate the prompt width. On Tue, Mar 19, 2013 at 09:31:06PM -0400, Yotam Barnoy wrote: >I hope this is the right place to report this. >On OSX, if I open a tmux pane and my .bashrc happens to assign a color to >the prompt using the ANSI escape sequences (e.g. #PS1="\e[0;34m\h:\W\$ >\e[m"), I get an odd problem. Whenever I get a line that fills up the >width of my pane, for example when paging through history, the terminal >misbehaves, usually by keeping a certain number of beginning characters >from that line on-screen. So for example if i had > >'my-computer$ sudo port upgrade foo..' (pretend it's a full line) > >and then I paged through history using the up arrow, once I encountered >the above line in history I'd get > >'my-computer$ sudo port upg rt install bar' > >on my terminal. The first characters of the wide line are stuck there and >won't go away. This makes correcting anything in history very difficult. > >Also, when I add to a line from history, the terminal won't scroll to the >next line once I fill up the line, but will scroll onto the same line. > >Removing the color escape sequences from the command prompt solves this >issue, but is obviously not the fix I want. > >Thanks > >Yotam Barnoy > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > ___ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Should copy-pipe use a (writable) job?
Hmm maybe I'm being an idiot and it is ok, let me look at it again later. Stdin/stdout/stderr are normally all the same fd anyway of course. On Tue, Mar 19, 2013 at 11:01:00PM -0500, Chris Johnsen wrote: > On Tue, Mar 19, 2013 at 4:19 PM, Nicholas Marriott > wrote: > > Ok thanks. My only concern is sharing the same fd for stdin and stdout - > > what happens if the copy-pipe command prints something? > > On my system (Mac OS X 10.8.3, which is supposed to be similar to > BSD systems), having the copy-pipe command write to its stdout works > okay. The output ends up in the job->event->input buffer (I checked > with some debug code in job_free that prints out the "input" buffer > if it is not empty); the data sent by copy-pipe ends up on the > command's stdin as usual. The two directions do not appear mixed or > interleaved in any way. Do you expect something different might > happen on other systems? > > My assumption is that socketpair() arranges the pair as if they had > gone through the regular process of bind/listen/accept and connect, > just without having to name one side. Thus, I expected that (even > after being duped) data written to the first could only be read form > the second, and vice versa (this appears to be what happens on my > system). > > I found a couple of instances in the portable OpenSSH code where one > side of a socketpair() is duped to both stdin and stdout, but I also > noticed that several platforms opt to use a pair of pipe()s instead > of socketpair(). Many of these systems seem "old" to me, but HP-UX > stood out as one that tmux supports (also SunOS 4?). > > The libevent docs say that bufferevent_new does not support pipe > fds, but I suppose we could use two socketpairs that have each been > shutdown to half duplex in opposite directions. > > Alternatively, copy-pipe could be implemented as a new, write-only > job variant instead of the read-write approach that this minimal > implementation ends up with. > > -- > Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Should copy-pipe use a (writable) job?
On Wed, Mar 20, 2013 at 2:18 AM, Nicholas Marriott wrote: > Hmm maybe I'm being an idiot and it is ok, let me look at it again > later. Stdin/stdout/stderr are normally all the same fd anyway of > course. Having maintained tmux as cross-platform project, you probably have a good feel for where the sharp cross-platform edges lurk, so I welcome further consideration of the right approach. I would certainly not attempt to claim that my implementation is definitely cross-platformly correct, just that it seemed like a reasonable approach, and that "it works for me" (for all _that_ is worth). Portable OpenSSH certainly seems to have encountered some reasons for avoiding socketpair on some platforms; the details of exactly why are a bit murky though. I poked around in the history and found some corresponding mailing list messages, but none of them really gave much detail about what exactly was failing (mostly just that switching to pipes fixed a problem on several platforms). -- Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Should copy-pipe use a (writable) job?
Chris Johnsen writes: > Having maintained tmux as cross-platform project, you probably have > a good feel for where the sharp cross-platform edges lurk, so > I welcome further consideration of the right approach. I would > certainly not attempt to claim that my implementation is definitely > cross-platformly correct, just that it seemed like a reasonable > approach, and that "it works for me" (for all _that_ is worth). tmux's portability is inherently limited anyway by the fact that it relies on the ability to pass file descriptors over Unix domain sockets. That prevents it from being ported to e.g. Cygwin. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Should copy-pipe use a (writable) job?
This is a little misleading - to my knowledge Cygwin is the only major platform that claims to be vaguely Unix-like and lacks SCM_RIGHTS or some way of passing file descriptors. Certainly the only one anyone has suggested porting tmux to. So I would say it is a limit of Cygwin or the Windows platform that prevents tmux being ported, not an inherent limit of tmux. BTW POSIX specifies SCM_RIGHTS, although merely as "access rights" not specifically file descriptors. Still, are there any implementations that treat it as anything else? On Wed, Mar 20, 2013 at 09:52:03AM +0100, Romain Francoise wrote: > Chris Johnsen writes: > > > Having maintained tmux as cross-platform project, you probably have > > a good feel for where the sharp cross-platform edges lurk, so > > I welcome further consideration of the right approach. I would > > certainly not attempt to claim that my implementation is definitely > > cross-platformly correct, just that it seemed like a reasonable > > approach, and that "it works for me" (for all _that_ is worth). > > tmux's portability is inherently limited anyway by the fact that it relies > on the ability to pass file descriptors over Unix domain sockets. That > prevents it from being ported to e.g. Cygwin. > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > ___ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Should copy-pipe use a (writable) job?
socketpair hasn't caused any issues so far, OpenSSH are much more concerned about supporting older platforms than I am. On Wed, Mar 20, 2013 at 03:38:08AM -0500, Chris Johnsen wrote: > On Wed, Mar 20, 2013 at 2:18 AM, Nicholas Marriott > wrote: > > Hmm maybe I'm being an idiot and it is ok, let me look at it again > > later. Stdin/stdout/stderr are normally all the same fd anyway of > > course. > > Having maintained tmux as cross-platform project, you probably have > a good feel for where the sharp cross-platform edges lurk, so > I welcome further consideration of the right approach. I would > certainly not attempt to claim that my implementation is definitely > cross-platformly correct, just that it seemed like a reasonable > approach, and that "it works for me" (for all _that_ is worth). > > Portable OpenSSH certainly seems to have encountered some reasons > for avoiding socketpair on some platforms; the details of exactly > why are a bit murky though. I poked around in the history and found > some corresponding mailing list messages, but none of them really > gave much detail about what exactly was failing (mostly just that > switching to pipes fixed a problem on several platforms). > > -- > Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Performing math using environment variables
Well, everything ended up a success. Found the missing dependencies, compiled, copied to /usr/bin, and wow that is a nice feature in resize-pane. Thanks everyone who helped, complete success. - Hameed On Tue, Mar 19, 2013 at 7:31 PM, Hameed Gifford wrote: > Okay, I figured out the autogen.sh, no one told me it depended on autoconf > and automake... > > Anyway, ./autogen.sh outputs this: > > $ ./autogen.sh > configure.ac:18: installing `etc/compile' > configure.ac:9: installing `etc/config.guess' > configure.ac:9: installing `etc/config.sub' > configure.ac:7: installing `etc/install-sh' > configure.ac:7: installing `etc/missing' > Makefile.am: installing `etc/depcomp' > Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf > line 195. > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf > line 195. > > Which I'm assuming is ok, since ./configure && make went ahead on its > merry way: > > $ ./configure && make > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking whether gcc and cc understand -c and -o together... yes > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking bitstring.h usability... no > checking bitstring.h presence... no > checking for bitstring.h... no > checking curses.h usability... no > checking curses.h presence... no > checking for curses.h... no > checking dirent.h usability... yes > checking dirent.h presence... yes > checking for dirent.h... yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking for inttypes.h... (cached) yes > checking libutil.h usability... no > checking libutil.h presence... no > checking for libutil.h... no > checking ncurses.h usability... no > checking ncurses.h presence... no > checking for ncurses.h... no > checking ndir.h usability... no > checking ndir.h presence... no > checking for ndir.h... no > checking paths.h usability... yes > checking paths.h presence... yes > checking for paths.h... yes > checking pty.h usability... yes > checking pty.h presence... yes > checking for pty.h... yes > checking for stdint.h... (cached) yes > checking sys/dir.h usability... yes > checking sys/dir.h presence... yes > checking for sys/dir.h... yes > checking sys/ndir.h usability... no > checking sys/ndir.h presence... no > checking for sys/ndir.h... no > checking sys/tree.h usability... no > checking sys/tree.h presence... no > checking for sys/tree.h... no > checking term.h usability... no > checking term.h presence... no > checking for term.h... no > checking util.h usability... no > checking util.h presence... no > checking for util.h... no > checking for gcc that whines about -I... yes > checking for glibc... yes > checking for library containing clock_gettime... -lrt > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for LIBEVENT... no > checking for library containing event_init... no > configure: error: "libevent not found" > > ... and it ends not so merry. Seriously, every time I try to compile some > form of source code, it backfires and there's usually a whole month before > I figure out what's wrong. I hate it! What am I missing? Where could I have > found it? > > - Hameed > > On Tue, Mar 19, 2013 at 11:56 AM, Stroller > wrote: > >> git is a way for developers to store and access programming code. >> >> The git repository (surely?) contains newer code than your distro's >> packages. >> >> The feature you require is relatively new and is (presumably) not >> available in release versions of tmux. >> >> >> On 18 March 2013, at 14:41, Hameed Gifford wrote: >> >> > Build from git, as in compile the code myself and not install fr
Re: Bug with colored prompt?
Thanks very much for the help guys. Sorry for blaming tmux. Yotam On Wed, Mar 20, 2013 at 3:16 AM, Nicholas Marriott < nicholas.marri...@gmail.com> wrote: > If you use invisible characters in your prompt you need to tell the > shell by enclosing them in \[ and \]. If you don't then it will > miscalculate the prompt width. > > > On Tue, Mar 19, 2013 at 09:31:06PM -0400, Yotam Barnoy wrote: > >I hope this is the right place to report this. > >On OSX, if I open a tmux pane and my .bashrc happens to assign a > color to > >the prompt using the ANSI escape sequences (e.g. #PS1="\e[0;34m\h:\W\$ > >\e[m"), I get an odd problem. Whenever I get a line that fills up the > >width of my pane, for example when paging through history, the > terminal > >misbehaves, usually by keeping a certain number of beginning > characters > >from that line on-screen. So for example if i had > > > >'my-computer$ sudo port upgrade foo..' (pretend it's a full line) > > > >and then I paged through history using the up arrow, once I > encountered > >the above line in history I'd get > > > >'my-computer$ sudo port upg rt install bar' > > > >on my terminal. The first characters of the wide line are stuck there > and > >won't go away. This makes correcting anything in history very > difficult. > > > >Also, when I add to a line from history, the terminal won't scroll to > the > >next line once I fill up the line, but will scroll onto the same line. > > > >Removing the color escape sequences from the command prompt solves > this > >issue, but is obviously not the fix I want. > > > >Thanks > > > >Yotam Barnoy > > > > -- > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_mar > > > ___ > > tmux-users mailing list > > tmux-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tmux-users > > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
