Hi On Fri, Jul 05, 2013 at 09:35:50AM -0700, Jack Bates wrote: > On 05/07/13 08:20 AM, Nicholas Marriott wrote: > >Hi > > > >On Wed, Jun 05, 2013 at 12:22:38PM -0700, Jack Bates wrote: > >>On 01/06/13 03:22 AM, Nicholas Marriott wrote: > >>>Hi > >>> > >>>What commands are you doing that regularly exceed 2048 bytes and why > >> > >>Thank you Nicolas, I often use tmux as part of scripts that run long > >>processes on Amazon EC2 instances (so if I get disconnected, I can > >>reattach later and check the progress). Here is an example: > >> > >> https://github.com/jablko/android/blob/master/Makefile > >> > >>>can't you put them in a temporary script or something and run that > >>>instead? > >> > >>Yes, that is how I work around the problem at the moment, it's just > >>unexpected and irritating when it happens. A higher limit wouldn't > >>eliminate the problem entirely (unless the limit was close to system > >>ARG_MAX), it would just save some irritation and avoid some workarounds. > >>I don't know what the tradeoffs of increasing COMMAND_LENGTH are... > > > >Well, the problem is that every command needs to pass this over the Unix > >domain socket so anything larger wouldn't be ideal. Also it'd mean > >bumping the protocol version and I really don't want to do that for > >this. > > > >I'm not sure it's worth it when very few people will hit this limit and > >even then you can do it with scripts instead. > > Fair enough. If someday in the future the protocol version will be > bumped anyway, maybe this could be a wishlist item?
Yes possibly although I wouldn't want to go higher than 4K, I'll bear it in mind. > > I haven't examined the protocol, might it be possible to encode the > command as a variable length, followed by the value? Or would that > be less than ideal as well? It is difficult to do variable length messages with the imsg API we use. Thanks > > I agree it's not a high priority. Just if there isn't a downside (if > the protocol version will be bumped anyway and if longer commands > can be accommodated without a penalty) it would be nice to have. > > In the mean time: scripts. > > Thank you for tmux Nicholas ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
