Timeline for How to run tmux session under network namespace
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 19 at 14:36 | history | edited | Jeff Schaller♦ | CC BY-SA 4.0 |
typo fix
|
| Oct 9 at 4:01 | vote | accept | Hashbrown | ||
| Oct 7 at 6:20 | comment | added | Hashbrown |
@StéphaneChazelas it's an example, nobody should use snippets from SE verbatim without learning what it does. The answer specifically says Use the option -S to specify a unix socket as the solution and offers "I'd run sudo ip....". Keep in mind others might want to use su instead of sudo, or maybe not switch back to the current user. It's a pretty language agnostic example where, no, it's not even specific to powershell (where not only would you have to use @tmuxArguments, but also $env:USER). Diving into how a calling script would use this instead of you typing it would be OOS
|
|
| Oct 7 at 6:17 | comment | added | Stéphane Chazelas |
If showing shell code not intended to be interpreted by a POSIX shell (or the shell implied by the question), you should make it clear what shell it's meant to be as in "use the powershell code below" (though rc or fish or zsh, proper Unix shells would also work here and is less likely to alienate your readers).
|
|
| Oct 7 at 6:14 | comment | added | Hashbrown | @StéphaneChazelas ooh I do like that, it stops you having to provide a nice directory for it to write to, too; just let tmux put it where it usually does. And testing now it does work the same, good spot (I came across -S whilst I was writing the question and after trying for ages and looking here for an answer haha). Thanks! | |
| Oct 7 at 6:13 | comment | added | Stéphane Chazelas |
When using -S, tmux doesn't check the ownership and permission of the path components, so using a socket with a fixed name in a world writable directory is very unsafe and could allow another user on the system take over the account. Better would be to use the -L option instead.
|
|
| Oct 7 at 6:11 | comment | added | Hashbrown |
You can see I'm pretty diligent about that if I am forced to work within bash, even deliberately using single 's if I know no variables are meant to be interpreted at all
|
|
| Oct 7 at 6:02 | comment | added | Hashbrown |
@cas I use powershell, this isnt an issue. $var is always a single parameter, and if you deliberately want it expanded you have to do that consciously. If you tried to use the above example verbatim in my scripts, $tmuxArguments would just be a single string and wouldnt do much (basically only permitting a or new). No mention of bash in this post!
|
|
| Oct 7 at 5:00 | comment | added | cas | I used to advise "Double-quote your variables except in the few rare instances when you know you want the shell to do word-splitting (e.g. to pass multiple args to a program)". Now my advice is "Always double quote your variables. Use an array where you might otherwise be tempted to rely on shell word-splitting (e.g. to pass multiple args to a program)" | |
| Oct 7 at 5:00 | comment | added | cas |
+1 nice solution (and good question), but you should a) double-quote your variables, and b) use an array for $tmuxArguments - a single string var containing space separated options kind of works but is very fragile and inflexible (there are some things, esp involving args which need to be quoted, that are easy to do using array elements but very difficult with just a single string). e.g. sudo ip netns exec "$namespace" sudo -u "$USER" tmux -S "/tmp/$namespace.tmux" "${tmuxArguments[@]}"
|
|
| Oct 7 at 3:49 | history | answered | Hashbrown | CC BY-SA 4.0 |