Giter Club home page Giter Club logo

muxed's Introduction

Muxed - “Another TMUX project manager”

Build Status

Drop muxed in to your $PATH and take it for a spin. Happy to receive feature requests or bug reports!

Muxed

Muxed: Provides the functionality for creating, opening and parsing your project configs to launch a TMUX session.

Snapshot: Experimental : Create a config file based on a running tmux session.

Installation

Download a release:

See the releases page for muxed packages. Download and untar the package as desired. Make sure the bin is somewhere in your $PATH. I generally move the bins in to /usr/local/bin.

$ tar -xvzf muxed-VERSION-SYSTEM.tar.gz
x muxed
$ mv muxed /usr/local/bin
$ muxed --help
$ muxed my_new_project

From Homebrew taps

This will add a tap to install a pre-compiled Muxed bin.

$ brew tap brianp/homebrew-muxed
$ brew install muxed_bin

For development

With Docker

Docker commands are long so I use a make file that points all the commands to a runing docker container.

$ git clone [email protected]:brianp/muxed.git
$ export MUXED_ENV=nix
$ make build
$ make start
$ make cargo cmd='test --workspace --color=always'

From source:

Have rust stable installed. Clone this repo. Then run cargo to build the source, and again use cargo to run the app.

$ git clone [email protected]:brianp/muxed.git
$ cargo build
$ cargo run -- --help
$ cargo test --workspace --color=always

Setup

1. Create a new project file.

If this is your first run, muxed will create the ~/.muxed/ directory for you.

$ muxed new my_project
Looks like this is your first time here. Muxed could't find the configuration directory: `/root/.muxed`
Creating that now 👌

✌ The template file my_project.yml has been written to /root/.muxed
Happy tmuxing!

The generated template will look like this (but with some inline docs):

root: "~/"
windows:
  - editor:
      layout: "main-vertical"
      panes: ["vi", "ls -alh"]
  - processes: "ls /proc"
  - logs: "tail -f /var/log/dmesg"

This config will create a new tmux session with three windows named editor, processes and logs. By default your view will be on the first window opened, on the first pane, which in this case is vi in the editor window. The first window will have two panes split vertically, the left will have the editor vi running and the right will have a shell listing of your current working directory.

2. Edit your template

Now you can use your favourite editor and make changes to the config as desired. This makes the assumption you have an $EDITOR env var set.

$ muxed edit my_project

3. Open TMUX with your muxed config

$ muxed my_project

Usage Options

Usage:
    muxed (list | ls)
    muxed [flags] [options] <project>
    muxed edit [options] <project>
    muxed load [flags] [options] <project>
    muxed new [flags] [options] <project>
    muxed snapshot [flags] [options] <project>
    muxed (-h | --help)
    muxed (-v | --version)

Flags:
    -d                  If you want to create a muxed session without connecting to it
    -f                  Overwrite existing file if one exists
    --debug             Prints debug information while executing (project opening only)
    -h, --help          Prints help information
    -v, --version       Prints version information

Options:
    -p <project_dir>    The directory your project config files live in. Defaults to ~/.muxed/
    -t <session>        The name of the running TMUX session to codify

Args:
    <project>           The name of your project to open

Subcommands:
    list                             List the availiable project configs
    edit <project>                   Edit an existing project file
    load <project>                   Load the specified project, this is the default command
    new <project>                    To create a new project file
    snapshot -t <session> <project>  Capture a running session and create a config file for it

Inspiration

This project has been inspired by the work done on the tmuxinator project. Check it out for a ruby based tmux session management solution.

Copyright

Copyright (c) 2014-2020 Brian Pearce. See LICENSE for further details.

muxed's People

Contributors

brianp avatar coreyja avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

muxed's Issues

[Feature Request]`list` when piped should be New Line deliminated

System Info

OS: Mac OS 11.1
Muxed Version: v0.8.2

Description

When piped muxed list displays all projects on the same line

While this looks great when used interactively in the terminal, when piped and used in scripts its more common and more useful to be delimited by newlines. Realized this in my current workflow where I am using sed to replace tabs with newlines to make muxed list more script-able

Workarounds

This can be workaround by using sed. The following produces new line delimited output

muxed ls | sed -e "s/\t\t/\n/g"

Steps to reproduce

  • muxed ls | cat

Expected

project_1
project_2
project_3

Actual

project_1 project_2 project_3

BUG: Cannot handle directories with spaces in it

I know, it's bad form to have spaces in directory names. But when I used one of my existing tmuxinator configuration files that opens up a directory with spaces in it, muxed incorrectly parses only the first word instead of the entire string.

Config:

# ~/.tmuxinator/jps-ledger.yml

name: jps-ledger
root: ~/JustPlainSimple Technologies Inc./financials/ledgers
...

Output:

cd ~/JustPlainSimple Technologies Inc./financials/ledgers
git status
greenhole:Downloads scott$ cd ~/JustPlainSimple Technologies Inc./financials/ledgers
git status
-bash: cd: /Users/scott/JustPlainSimple: No such file or directory
greenhole:Downloads scott$ git status
fatal: Not a git repository (or any of the parent directories): .git
greenhole:Downloads scott$

Travis OSX Builds are failing

System Info

OS: Mac OSX 10.13.3
Muxed Version: MASTER @ 41e7bce
Running in: Travis

Description

OSX builds in travis are failing with error:

error: linker `x86_64-apple-darwin14-clang` not found
  |
  = note: No such file or directory (os error 2)
error: aborting due to previous error
error: Could not compile `libc`.

I believe this is because the cargo config .cargo/config files points the apple-darwin target to a clang linker that doesn't exist. The travis system uses the x86_64-apple-darwin17-clang linker.

[target.x86_64-apple-darwin]
linker = "x86_64-apple-darwin14-clang"

We should probably not commit the cargo config to allow for OS defaults. And have the OSX docker cross compiler generate the config file internally.
Or optionally overwrite the desired setting in travis.

Steps to reproduce

  • Have build run in OSX Travis env

Expected

It passes.

Actual

It errors out.

Stacktrace

$ cargo build --verbose
   Compiling libc v0.2.49
       Fresh quote v0.3.15
     Running `rustc --crate-name build_script_build /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.49/build.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=8d6815381988d0cd -C extra-filename=-8d6815381988d0cd --out-dir /Users/travis/build/brianp/muxed/target/debug/build/libc-8d6815381988d0cd -C linker=x86_64-apple-darwin14-clang -L dependency=/Users/travis/build/brianp/muxed/target/debug/deps --cap-lints allow`
       Fresh void v1.0.2
       Fresh unicode-xid v0.0.4
       Fresh serde v0.8.23
       Fresh utf8-ranges v1.0.0
       Fresh regex-syntax v0.4.0
   Compiling lazy_static v0.2.4
     Running `rustc --crate-name lazy_static /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-0.2.4/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=ee8b007376f7af6d -C extra-filename=-ee8b007376f7af6d --out-dir /Users/travis/build/brianp/muxed/target/debug/deps -C linker=x86_64-apple-darwin14-clang -L dependency=/Users/travis/build/brianp/muxed/target/debug/deps --cap-lints allow`
   Compiling strsim v0.6.0
     Running `rustc --crate-name strsim /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/strsim-0.6.0/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=82682e8fc0d9abaa -C extra-filename=-82682e8fc0d9abaa --out-dir /Users/travis/build/brianp/muxed/target/debug/deps -C linker=x86_64-apple-darwin14-clang -L dependency=/Users/travis/build/brianp/muxed/target/debug/deps --cap-lints allow`
error: linker `x86_64-apple-darwin14-clang` not found
  |
  = note: No such file or directory (os error 2)
error: aborting due to previous error
error: Could not compile `libc`.
Caused by:
  process didn't exit successfully: `rustc --crate-name build_script_build /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.49/build.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=8d6815381988d0cd -C extra-filename=-8d6815381988d0cd --out-dir /Users/travis/build/brianp/muxed/target/debug/build/libc-8d6815381988d0cd -C linker=x86_64-apple-darwin14-clang -L dependency=/Users/travis/build/brianp/muxed/target/debug/deps --cap-lints allow` (exit code: 1)
warning: build failed, waiting for other jobs to finish...

Add a `new` subcommand

This subcommand should create a new project folder in the supplied project directory (default or passed by -p).

The project file should contain a simple layout with explanations for available options.
ex.

When a project is called to open but a session exists with the same name

Situation

Once a project has been opened with muxed
OR
A tmux session has been started with the same name as a muxed project

And muxed is called to open a project with the same name as the session already running... (contd)

Current behaviour:

... the first muxed command in the sequence will fail. The remaining commands will all run against the existing named session. Causing undesired effects on the running session.

Expected behaviour

... muxed should recognize that a session with that name already exists and attach to it without running any additional commands.

base-pane-index is not repsected

If the users tmux config has base-pane-index is set to 1 new panes will improperly assume a 0 index and fail to create the appropriate pane splits and command execution.

Although I've been trying to avoid it, it looks like I'll have to read in users tmux configs to see what the appropriate base index for panes is.

Snapshot is interpreting single pain windows weird

System Info

OS: Mac OSX 10.14.3
Muxed Version: MASTER @ b3a0703

Description

Snapshot is outputting config files where single pane windows are being written like multi-pane windows. They include active options (which seems like a bug), layout, and panes.
A hand written config like:

windows:
  - make: ''
  - vim: vim .
  - bash: ''

Will produce a snapshot config like:

windows:.                         
  -                              
    make:                        
      active: true                
      layout: "5ad5,119x32,0,0,35"
      panes:                     
        - ""                      
  -                              
    vim:                         
      active: false               
      layout: "5ad6,119x32,0,0,36"
      panes:                     
        - vim .                   
  -                              
    bash:.                        
      active: false               
      layout: "5ad7,119x32,0,0,37"
      panes:                
        - ""                      

This seems to lead into additional problems when executing the snapshot config. It may be trying to send commands to the wrong pane? I'm not entirely sure yet. But if a window only has 1 pain, we should avoid writing layout and pane information and use the shorthand syntax. (Although we still need a way to signify active for single pane windows.)

Questions

  • What to do about active?
  • Is a single pane still not considered the 0 indexed pane for a window?

Steps to reproduce

  • Open a tmux session with a single pane window
  • Execute a command in that window. tail -f /usr/logs/system.log
  • snapshot the session muxed snapshot -t 0 test
  • re-run the session muxed test

Expected

A single window session with a log tail running

Actual

A single window session with nothing running

Accept a `name` setting for the session name

Currently the session name is based off the filename of the project file.
Allow a name option in the settings.yml to define a session name.

The name should not be escaped, downcased, underscored, or otherwise manipulated.

ex.
muxed.yml

name: "This Project"
root: "~/"
windows:
  - editor:
      layout: "main-vertical"
      panes: ["vi", "ls -alh"]
  - processes: "ls /proc"
  - logs: "tail -f /var/log/dmesg"

When a tmux session is created and checked using tmux ls the result will be:

Before:

muxed: 3 windows (created Sun Sep 25 21:23:04 2016) [123x29]

After:

This Project: 3 windows (created Sun Sep 25 21:23:04 2016) [123x29]

Add a Pre command for all windows

The pre option should accept a system command to execute. This will be executed before any of the window specific commands are executed.

It should exist at the root of the config file as such:

root: "~/"
pre: "rbenv shell 2.2.0"
windows:
  - editor:
      layout: "main-vertical"
      panes: ["vi", "ls -alh"]
  - processes: "ls /proc"
  - logs: "tail -f /var/log/dmesg"

Should bootstrap the configuration directory upon first run

Version 0.3.1

I ran muxed exampleproject and it complained about the file not being in the default configuration directory ($HOME/.muxed). That's because I hadn't copied the tmuxinator file over to muxed yet. However, what I expected muxed to do was to create the default configuration directory upon first call (letting me know that it did this). I'm guessing that I have to create that configuration directory manually.

I expected something like:

$ muxed
Looks like this is your first time here.  I could not find default configuration directory: $HOME/.muxed.  Creating it now.

.. normal output here ...

This only runs when the default (or given) configuration directory cannot be found.

Have test executions output commands to /dev/null

Currently when the test suite executes window/pane specific commands it will end up in the bash history. Make sure all test commands are piped to /dev/null to create less chatter in the history.

Allow forced file creation for new subcommand

System Info

OS: Mac OS 10.15.1
Muxed Version: v0.7.2-development

Description

When running the subcommand muxed new test if the file exists an error is thrown. The same error occurs with the -f flag which should overwrite the existing file if one exists.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Could not create the file /Users/brianp/.muxed/test.yml. Error: File exists (os error 17)"', src/libcore/result.rs:1189:5

Questions

The code isn't written to respect the -f flag but it should.
Additionally the error message should be much nicer.

Steps to reproduce

  • Run muxed new test
  • Re-run muxed new -f test

Expected

The test.yml file to be overwritten.

Actual

An error is thrown.

Windows & Panes should support no value for command execution

When no value is present for window command execution muxed raises an exception. It is valid yaml to have no characters for a the value of a key.

Window example exception raising config: ~/.muxed/test.yml

windows:
  - logs:

Pane example

windows:
  - logs:
    panes:
      -

Current behaviour

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ cargo run test
     Running `target/debug/muxed test`
thread '<main>' panicked at 'Bad exec command', ../src/libcore/option.rs:704
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Process didn't exit successfully: `target/debug/muxed test` (exit code: 101)

Expected behaviour

Muxed should open tmux and no command should be executed in that window or pane.

[Feature Request] Visualize running sessions in list command

System Info

OS: Mac OS 11.1
Muxed Version: v0.8.2

Feature Description

It would be cool if the list command identified sessions that are currently running in tmux.

For example sessions could be pre/post fixed with an asterisk to identify there is an active session for this project. This could also be toggled via a command line flag is desired too

Reason

I currently use Prefix-s or choose-tree to switch between currently running sessions in tmux. I sometimes then want to switch to a project I don't have currently open. I developed a different workflow recently that works well! Using tmux popup -KER 'muxed load $(muxed ls | sed -e "s/\t\t/\n/g" | fzf)' I can use the new tmux popup command to create a popover to fuzzy find and select the project I want to open. If these was a way to identify currently running sessions like this it would make it just that much more useful!

👋 I would love to help out with this, I've been missing Rust recently lol. But wanted to see what feedback you had before getting started! This is a pretty recent addition to my workflow but I've been liking it a lot so far

Quoting root dirs causes `~/` to stop working

The unix command cd "~/" does not work. When double quoted you have to use variables such as cd "$HOME".

This isn't an ideal user experience. I want to be able to define root: ~/. A solution would be to handle root values with spaces differently then without spaces, although this means root: ~/Dir With Space/project would still fail. Maybe converting any usage of ~/ behind the scenes to $HOME?

Regression from #11

Example broken config:

root: "~/"
windows:
  - editor:
      layout: "main-vertical"
      panes: ["vi", "ls -alh"]"

Allow the `pre` command to accept an array of values to execute

The config option pre expects content to be in the form of a String but an array would be perfectly acceptable. Allow pre to be defined like below:

pre:
  - brew services start mongodb26
  - brew services start elasticsearch

Current behaviour:
If pre is not in String format the option is simply ignored.

Desired behaviour:
Accept pre as a String or Array.

Add an `edit` subcommand

Add a subcommand that will open the users default editor to make changes on the supplied project file.

Ex.

$ muxed edit my_project

Where vi would open to edit the file ~/.muxed/my_project.yml

The subcommand should also accept -p as an argument for path where to find the file.
Ex.

$ muxed edit my_project -p ~/.my_muxed_projects/

Where vi would open to edit the file ~/.my_muxed_projects/my_project.yml

Calling edit without an argument opens a file called edit.yml

System Info

OS: Mac OS 10.15.1
Muxed Version: v0.7.2-development

Description

When muxed edit is called without a <project> argument it opens a project file called edit.yml.

Steps to reproduce

  • Run muxed edit

Expected

Get a message that says an argument needs to be supplied.

Actual

A new file edit.yml is opened, but not saved.

Support `load`ing while already in a tmux session

System Info

OS: Mac OS 10.15.2
Muxed Version: v0.8.0

Description

When already inside a tmux session, muxed errors with a warning from tmux about nested sessions.
sessions should be nested with care, unset $TMUX to force

Steps to reproduce

  • tmux
  • muxed new test
  • muxed test

Expected

Muxed creates a detached session and switches tmux to that session

Actual

A tmux error message is printed to the terminal
sessions should be nested with care, unset $TMUX to force

Use Case

I have my terminal default to opening a tmux session, so I am almost never in a bare bash terminal. This reduces the usability to muxed since it can't be used to load a new project while in a tmux session.

Calling new without an argument creates a file called new.yml

System Info

OS: Mac OS 10.15.1
Muxed Version: v0.7.2-development

Description

When muxed new is called without a <project> argument it creates a project file called new.yml.

Steps to reproduce

  • Run muxed new

Expected

Get a message that says an argument needs to be supplied.

Actual

A new file new.yml is created

Default focus to the first window

Currently after a Muxed session has started, default window focus is on the last opened window & pane.

Apply focus to the first pane in the first window of the session.

The Pre option has unexpected behaviour

Currently using pre in a config will have execute the command in every window/pane.

I believe the user expected behaviour is for pre to be run once, before the tmux session is started. Where another option such as pre_window is something that will get run in every window/pane before the window/pane specific commands.

For this issue, I want to adjust the behaviour of the existing pre option. In a later issue I will add a pre_window option.

Usage is unclear

The README is sorely lacking for info.
Because I'm not a total Rust noob, I reach for Cargo which told me to execute a command. I guessed at cargo build which seemed to do the trick. Unfortunately, that alone isn't enough to get going:

↳ target/debug/muxed
thread '<main>' panicked at 'index out of bounds: the len is 1 but the index is 1', ../src/libcollections/vec.rs:1134

I presume this is because I need to pass a commandline parameter?
(Sorry, haven't started looking at source yet - just trying to get my bearings first.)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.