an alternative way to pass directories out back to the shell, without costume wrappers

[codinganovel]

Hi! I've been researching solutions to the directory inheritance problem that lf (and most CLI tools) face. I really appreciate how lf addresses this with the lfcd wrapper scripts - it's a clean solution that works well.
I've been exploring an alternative approach that might simplify the setup process for users, and I wanted to get the community's thoughts on the trade-offs.
Current approach (lfcd scripts)

Wrapper function captures lf's output via -print-last-dir
Shell function manually calls cd after lf exits
Requires users to source shell-specific scripts
Works reliably across different workflows

Alternative approach (process replacement)
Instead of wrapper scripts, the application itself could handle the transition:

When lf exits, instead of returning to the shell immediately
lf replaces its own process with a small transition script:

bash#!/bin/bash
cd "/final/directory"
exec $SHELL

User ends up in the final directory without any setup

the implementation I came up with for testing
exact changes
possible future
autocd docs themselves

While lf's current lfcd scripts exemplify classic Unix composability by externalizing
the cd logic, my proposed --autocd method offers an alternative, integrated approach.
This feature is entirely opt-in; when the --autocd flag is not used, lf functions as a standard Unix command, fully compatible with pipes and redirections. By leveraging the exec syscall—a fundamental Unix primitive—to directly transition the shell, this approach provides a seamless user experience without fundamentally violating Unix principles, offering a different design choice for how an application can integrate its navigational state with the user's shell.
im looking for advise? am I being dumb with my approach? I feel like it works reliably?

[CatsDeservePets]

To be honest, this seems more hacky then the current approach. I don't like this hardcoded script at all. It assumes bash and will most likely crash on Windows.

[CatsDeservePets]

It definitely is a unique approach I haven't seen before. I also did not want to discourage you to explore this deeper.

[codinganovel]

Thanks for the follow-up! I really appreciate you taking the time to share your perspective - it definitely helps me understand the trade-offs better.
I should mention, I don't get discouraged easily! 😄 Actually, since our conversation yesterday about the shortcomings of my proof-of-concept, I spent the entire day building a basic Go library version that tries to handle the cross-platform complexity (Windows cmd/PowerShell, macOS shells, Linux, etc.) internally.
It's definitely still a v0.2-level thing, but I think it's something I'm going to keep maintaining and see if I can integrate into other applications. I've already got a working fork of fzf using it, and the library approach seems to make integration much simpler.
If you have a moment and don't mind, I'd actually really value your take on whether my implementation covers the edge cases you'd expect - especially around cross-platform behavior. I only have a Mac to develop on, so I'm honestly a bit blind to Windows-specific gotchas and Linux distribution differences that someone with your experience would probably spot immediately.
Thanks again for the thoughtful discussion - it really helped me think through the design decisions!
autocd-go

[codinganovel]

did a basic integration, it's working, tho it's very basic. here

[CatsDeservePets]

Hello again, @codinganovel.

I am really busy these days, I will take a look within the next few days.

[codinganovel]

I appreciate you, massively, your first response really helped me think through and a bit more around the whole project

[joelim-work]

By using exec to turn lf into a shell, you now end up with a shell running within the original shell. And if you keep running lf in this way you will end up with many layers of shells.

[codinganovel]

yeah thats true, something I originally did not consider, at the moment, im having the library check for SHLVL every time it gets called, and check and warn users about performance around 15 nested shells deep, its not the correct number probably but was where my own test devices started to slow down a little, windows doesn't have an proper equivalent to SHLVL as far as I know, but I don't have a Windows PC and I kind of have never had one so I'm working off of research for that specific platform. one final note about performance for me was that this sort of shell nesting through entire workflows would only happen if every single app used this approach for Directory inheritance, I have a work session report of the day I was working exactly around this. shlvl

[veltza]

The nested shell also increments LF_LEVEL, which triggers the nested lf instance warning when you launch lf again:

&[ "$LF_LEVEL" -eq 1 ] || lf -remote "send $id echoerr \"Warning: You're in a nested lf instance!\""

[codinganovel]

Oh, I'm sorry, you're misunderstanding me, I don't intend to ask you to merge this into the app in any shape or away or form I'm simply here asking for advice on my approach that's it, in hindsight, maybe posting to the idea section or wasn't the best first choice. The fork is also just temporary. I won't be maintaining it in any shape or form. I'll delete the repo.

[joelim-work]

Sorry I wasn't completely sure so I was just trying to be clear, especially since you already went to the trouble of writing a dedicated library for this. Other file managers like ranger have similar 'cd on quit' functionality - you can try asking there for advice too,

[codinganovel]

ill be sure to do that, and I understand, but trust me Im way more than happy with lf just as it is :) and if you ended up taking a look, I'll appreciate your feedback very much, honestly, I've been thinking the entirety of my afternoon and I'm thinking maybe my library will be a lot more focused if I just focus on UNIX based platforms

[CatsDeservePets]

@codinganovel
Let me tell you, Windows is pain in the ass when it comes to any sort of shell stuff. Only in 2016, Windows added support for ANSI escape codes back to the terminal (they had it at some point but removed it again) and luckily, the "new" Windows Terminal has it enabled by default these days. I always try writing my software (almost exclusively command line stuff) in a cross platform way and all weird quirks one has to do in order to make it work on Windows...
If your goal is to potentially target a bigger user base, support Windows.
If your goal is to (potentially) keep your sanity, just support UNIX systems.

[codinganovel]

@CatsDeservePets you are absolutely right, I went through the entire thing yesterday and stripped out all the windows and stuff and it turned out to be a lot more simpler to work with when you don't have all of that, and honestly at the moment I only have a Mac and a really old raspberry pi 4 which I just use to cycle different other unix based system for testing, I was doing the Windows stuff using a mix of github actions and virtual machines and docker, I decided it probably makes sense for me to drop windows until I have a machine I can actually test on.