Open haberdashPI opened 8 months ago
In my case, there is a different limit. It's just 19 characters. 20 character long session names cause the session to never start.
$ zellij attach --create 1234567890123456789
Bye from Zellij!
$ zellij attach --create 12345678901234567890
^C
$ zellij --version
zellij 0.40.1
I want to add that this behavior just appeared out of nowhere, I didn't update zellij, only restarted my mac. It was temporarily resolved by updating to 0.40.1, but only for a few minutes.
I also tried deleting ~/Library/Caches/org.Zellij-Contributors.Zellij
and restarting once more, but that doesn't seem to have helped.
I thought this might've had something to do with maximum path lengths, but no:
$ cd /Users/feuh/Library/Caches/org.Zellij-Contributors.Zellij/0.40.1/session_info
$ cp -r circular-oboe AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
$ tree
.
├── AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
│ ├── initial_contents_1
│ ├── session-layout.kdl
│ └── session-metadata.kdl
├── circular-oboe
│ ├── initial_contents_1
│ ├── session-layout.kdl
│ └── session-metadata.kdl
└── erudite-hill
├── initial_contents_1
├── session-layout.kdl
└── session-metadata.kdl
5 directories, 12 files
$ zellij ls
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA [Created 1day 18h 38m 52s ago] (EXITED - attach to resurrect)
circular-oboe [Created 1day 18h 38m 52s ago] (EXITED - attach to resurrect)
erudite-hill [Created 1day 13m 10s ago] (EXITED - attach to resurrect)
$
$ zellij attach AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
^C
$ zellij attach circular-oboe
Session detached
Interestingly, the character limit seems to differ depending on the environment variables.
$ zellij a -c 12345679012345679012
Bye from Zellij!
$ direnv allow
direnv: loading ~/repos/Elli/.envrc
direnv: using asdf
direnv: Creating env file /Users/feuh/.cache/asdf-direnv/env/2818442693-1703597551-1586414608-3007758193
direnv: loading ~/.cache/asdf-direnv/env/2818442693-1703597551-1586414608-3007758193
direnv: using asdf maven 3.8.6
direnv: loading ~/.asdf/plugins/maven/bin/exec-env
direnv: using asdf terraform 1.5.7
direnv: using asdf nodejs 18.18.2
direnv: using flake ./env-flake
waiting for lock on profile '/Users/feuh/repos/Elli/.direnv/flake-profile'
waiting for lock on profile '/Users/feuh/repos/Elli/.direnv/flake-profile'
direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +ELLI_NPM_TOKEN +HOST_PATH +IN_NIX_SHELL +LD +LD_DYLD_PATH +MACOSX_DEPLOYMENT_TARGET +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_aarch64_apple_darwin +NIX_BUILD_CORES +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_aarch64_apple_darwin +NIX_CFLAGS_COMPILE +NIX_DONT_SET_RPATH +NIX_DONT_SET_RPATH_FOR_BUILD +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_IGNORE_LD_THROUGH_GCC +NIX_LDFLAGS +NIX_NO_SELF_RPATH +NIX_STORE +NM +PATH_LOCALE +RANLIB +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +TEMP +TEMPDIR +TMP +XDG_DATA_DIRS +ZERO_AR_DATE +__darwinAllowLocalNetworking +__impureHostDeps +__propagatedImpureHostDeps +__propagatedSandboxProfile +__sandboxProfile +__structuredAttrs +buildInputs +buildPhase +builder +cmakeFlags +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +dontAddDisableDepTrack +mesonFlags +name +nativeBuildInputs +out +outputs +patches +phases +preferLocalBuild +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH ~TMPDIR
$ zellij a -c 12345679012345679012
^C
Don't have more time to dig into this right now, but maybe that's a clue already?
Have the same problem on MacOS. For me it's 36 characters. I have no idea what is defining that length.
It's not a problem on Linux.
I was looking into validate_session
, the function, that is responsible for detecting session names, that are too long, as it's error messages are nonsensical.
There is a check for the maximal socket length, which is only performed if the target family unix is set. I am using linux, where it is set. If i bypass the test, my zellij also starts indefinetly hanging.
The total length, including the directory is relevant. This means that the maximum length for a socket name also depends on the directory of the socket.
It seems that, if i bypass the check, the client tries endlessly to connect to the server.
Edit: #2817 seems to be related
Should socket path length really depend on length of the directory where the session is started? Maybe it would be better to hash the directory name. (Or, if the name should be useful, when it is too long, take a suffix of the path and prepend it with a a short-ish base64-like string prefix of the hash).
You misunderstand. Zellij uses the same directory for every socket. There a socket named like the session is created. On my system the directory is "/run/user/\<uid>/zellij/\<version>/".
This means the length does not depend on the directory where the session is started. Just on the name of the session.
I think your Idea is a good one if applied to the session name.
However i do not know if it is simple to implement, as using a hash, that is too long will stop zellij from ever working on some systems.
Ah yes, that makes sense. Sorry for the confusion.
With even a short hash of the full name (e.g. 8 characters) you'd get a pretty low collision rate (64^8 = 281,474,976,710,656). Adding even a short suffix of the session name (e.g. 16 characters) would probably suffice to keep the pipe name descriptive while keeping the character length well below any plausible limits.
I found an issue with this idea. The sockets are used to find out which sessions are active. There is another mechanism needed for that if the name of the session can not be found by the name of the socket.
Edit: The session cache is possibly better for that anyway.
If I create sessions names longer than 40 characters zellij hangs.
The first command properly opens zellij, while the latter hangs indefinitely
This occurs on MacOS 14.3.1 regardless of the terminal I'm using (VSCode or iTerm2).