bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[annoyance/non-feature] On OS X, every process is "occupying" CWD, makin


From: Danyel Bayraktar
Subject: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.
Date: Tue, 16 Jan 2018 22:36:47 +0800

I asked on StackExchange prior to this: 
https://apple.stackexchange.com/questions/310965/stop-iterm2-from-using-disk-disk-cannot-be-ejected
 
<https://apple.stackexchange.com/questions/310965/stop-iterm2-from-using-disk-disk-cannot-be-ejected>

Initially I thought it was specific to the terminal emulator, but it is 
actually due to the design of OS X. My problem is that when cd’ing into the 
external drive to run an `ls`, I’m not really “using” it and should be able to 
eject it. The eject should only be impossible for the time span a process is 
actually running.

So my proposal would be to get rid of this annoyance:

Bash should idle in (e.g.) /tmp or /var/folders/xyz, i.e. occupy that file as 
‘CWD’ towards the OS, but obviously not expose this to depending code, so still 
spawn every child process/builtin/keyword inside the (memory-stored) cwd which 
will be updated with `cd` and used throughout.

The drawbacks of this are apparent: `lsof` would show a random irrelevant 
folder as `cwd` for bash and as such, would be backward incompatible. This 
could be mitigated by 1) only enabling this in OS X (I do remember disks can be 
ejected even if bash is occupying them), or (ill-performing), 2) only for 
external drives. Ill-performing because this will require checks after almost 
every CWD modification.

3) Honestly, the most obvious and backward-compatible solution would be to put 
this behind a shopt option, e.g. ‘shopt -s cwdspoof’. I don’t see any reason 
why this wouldn’t be feasible…

This is my first e-mail here — I would love to help implement this if you give 
me some pointers and a contribution guide.

Best regards,
Danyel.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]