Re: bug when 'cd ..' to a directory who's parent has been deleted

[Linda Walsh]

Chet Ramey wrote:

On 2/8/16 9:59 AM, Andreas Schwab wrote:
  

Chet Ramey  writes:



`cd ..' should fail, since the parent no longer exists, and the pathname
canonicalization should fail, since there's presumably no longer a valid
path to reach the current directory.  No value for $PWD is correct.
  

${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
this case, it doesn't fail.



Why would that be more reasonable than anything else?  It references a
path that doesn't exist.

  

Um...Not exactly.  As long as there's a handle open to the previous path,
it still exists (at least on linux and unix).

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Andreas Schwab]

Linda Walsh  writes:

> Um...Not exactly.  As long as there's a handle open to the previous path,
> it still exists (at least on linux and unix).

You cannot have handles on file names, only on files.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Andreas Schwab]

Chet Ramey  writes:

> It's still an unlikely scenario.

What do you mean with unlikely?  Removing some directory where there is
still a shell active can happen all the time.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Chet Ramey]

On 2/8/16 10:36 AM, Andreas Schwab wrote:
> Chet Ramey  writes:
> 
>> On 2/8/16 9:59 AM, Andreas Schwab wrote:
>>> Chet Ramey  writes:
>>>
 `cd ..' should fail, since the parent no longer exists, and the pathname
 canonicalization should fail, since there's presumably no longer a valid
 path to reach the current directory.  No value for $PWD is correct.
>>>
>>> ${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
>>> this case, it doesn't fail.
>>
>> Why would that be more reasonable than anything else?  It references a
>> path that doesn't exist.
> 
> Sorry, I misread the OP's message.  I didn't notice it's about the
> parent's parent, not the parent.

It's still an unlikely scenario.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Andreas Schwab]

Chet Ramey  writes:

> On 2/8/16 9:59 AM, Andreas Schwab wrote:
>> Chet Ramey  writes:
>> 
>>> `cd ..' should fail, since the parent no longer exists, and the pathname
>>> canonicalization should fail, since there's presumably no longer a valid
>>> path to reach the current directory.  No value for $PWD is correct.
>> 
>> ${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
>> this case, it doesn't fail.
>
> Why would that be more reasonable than anything else?  It references a
> path that doesn't exist.

Sorry, I misread the OP's message.  I didn't notice it's about the
parent's parent, not the parent.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Chet Ramey]

On 2/8/16 10:49 AM, Andreas Schwab wrote:
> Chet Ramey  writes:
> 
>> It's still an unlikely scenario.
> 
> What do you mean with unlikely?  Removing some directory where there is
> still a shell active can happen all the time.

Removing a non-empty directory is unlikely to happen.  If you assume, as
Greg does, the OP meant that the current directory and its parent were both
removed, it's more likely.  If you assume, as the OP said, that only the
parent is removed, it's unlikely.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Dave Rutherford]

On Mon, Feb 8, 2016 at 11:34 AM, Linda Walsh  wrote:
> Chet Ramey wrote:
>> On 2/8/16 9:59 AM, Andreas Schwab wrote:
>>> Chet Ramey  writes:
 `cd ..' should fail, since the parent no longer exists, and the
pathname
 canonicalization should fail, since there's presumably no longer a
valid
 path to reach the current directory.  No value for $PWD is correct.
>>> ${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
>>> this case, it doesn't fail.
>> Why would that be more reasonable than anything else?  It references a
>> path that doesn't exist.
> Um...Not exactly.  As long as there's a handle open to the previous path,
> it still exists (at least on linux and unix).

Really?
11:40:24 dave@Vger:~$ mkdir -p a/a
11:40:30 dave@Vger:~$ cd a/a
[remove a in another window]
11:40:49 dave@Vger:~/a/a$ touch file
touch: cannot touch ‘file’: No such file or directory

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Andreas Schwab]

Chet Ramey  writes:

> If you assume, as the OP said, that only the parent is removed, it's
> unlikely.

You cannot remove a non-empty directory, so this does not make sense.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Odd Beck]

Well, in all fareness, this is highly unlikely that it would happen, but it
did happen to me while I was cleanup up some rubbish in my filesystem. It
wasn't a big deal as I quickly realized what was happening.

Here's the way I reproduced it:

Terminal1:
mkdir -p ~/a/b
cd ~/a/b

Terminal2:
cd ~
rm -rf a/

Terminal1:
cd ..
cd: error retrieving current directory..


It might not be a huge issue, but I though I'd report it.

Best regards

Odd Beck

On Mon, Feb 8, 2016 at 7:48 PM, Chet Ramey  wrote:

> On 2/8/16 11:34 AM, Linda Walsh wrote:
>
> >> Why would that be more reasonable than anything else?  It references a
> >> path that doesn't exist.
> >>
> >>
> > Um...Not exactly.  As long as there's a handle open to the previous path,
> > it still exists (at least on linux and unix).
>
> The actual filesystem objects still exist, but the named references to them
> (pathnames) do not.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Mike Frysinger]

On 08 Feb 2016 10:38, Chet Ramey wrote:
> On 2/8/16 10:36 AM, Andreas Schwab wrote:
> > Chet Ramey  writes:
> >> On 2/8/16 9:59 AM, Andreas Schwab wrote:
> >>> Chet Ramey  writes:
> >>>
>  `cd ..' should fail, since the parent no longer exists, and the pathname
>  canonicalization should fail, since there's presumably no longer a valid
>  path to reach the current directory.  No value for $PWD is correct.
> >>>
> >>> ${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
> >>> this case, it doesn't fail.
> >>
> >> Why would that be more reasonable than anything else?  It references a
> >> path that doesn't exist.
> > 
> > Sorry, I misread the OP's message.  I didn't notice it's about the
> > parent's parent, not the parent.
> 
> It's still an unlikely scenario.

fwiw, i see it semi often when dealing with build systems:
- use a package manager to build a package
- PM creates a fresh new dir tree to build/install
- build fails for whatever reason
- go into that directory tree (usually multiple levels)
- figure out problem
- fix it in a diff window
- re-run the PM command to build the package in shell in build tree
- that shell's active tree is now gone and you get shell-init errors

just google "shell-init error retrieving current directory" to see
many other people randomly running into it as well.

i see it weekly, but i know what's going on, and i build a lot of
code.  so is it "unlikely" ?  i guess in the larger scheme of things
compared it might be, but i wouldn't say it's so unlikely that a user
would never see it.
-mike


signature.asc
Description: Digital signature

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Odd Beck]

And I now understand the initial confusion as I attached the wrong picture
in the first email. The picture I was supposed to send included both
terminal windows which would (most likely) have explained the situation
better than just that one terminal :-S



On Tue, Feb 9, 2016 at 7:16 AM, Odd Beck  wrote:

> Well, in all fareness, this is highly unlikely that it would happen, but
> it did happen to me while I was cleanup up some rubbish in my filesystem.
> It wasn't a big deal as I quickly realized what was happening.
>
> Here's the way I reproduced it:
> 
> Terminal1:
> mkdir -p ~/a/b
> cd ~/a/b
>
> Terminal2:
> cd ~
> rm -rf a/
>
> Terminal1:
> cd ..
> cd: error retrieving current directory..
> 
>
> It might not be a huge issue, but I though I'd report it.
>
> Best regards
>
> Odd Beck
>
> On Mon, Feb 8, 2016 at 7:48 PM, Chet Ramey  wrote:
>
>> On 2/8/16 11:34 AM, Linda Walsh wrote:
>>
>> >> Why would that be more reasonable than anything else?  It references a
>> >> path that doesn't exist.
>> >>
>> >>
>> > Um...Not exactly.  As long as there's a handle open to the previous
>> path,
>> > it still exists (at least on linux and unix).
>>
>> The actual filesystem objects still exist, but the named references to
>> them
>> (pathnames) do not.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, ITS, CWRUc...@case.edu
>> http://cnswww.cns.cwru.edu/~chet/
>>
>
>

Bogus value of variable BASH

[David Hunt]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -Wall
uname output: Linux unknown 3.13.0-77-generic #121-Ubuntu SMP Wed Jan
20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 11
Release Status: release

Description:
On my notebook running Ubuntu 14.04.3 LTS /bin/sh points to dash, not 
bash.
To get sh behaviour from bash I use the command `exec -a sh /bin/bash'.
When I do so bash sets BASH to /bin/sh, which it demonstrably is not.
The situation:
none@unknown:~$ ls -l /bin/bash /bin/sh
-rwxr-xr-x 1 root root 1021112 Oct  7  2014 /bin/bash
lrwxrwxrwx 1 root root   4 Feb 19  2014 /bin/sh -> dash

Repeat-By:
The demonstration:
none@unknown:~$ exec -a sh /bin/bash
sh-4.3$ [ "$BASH" -ef "/proc/$$/exe" ] || declare -p BASH
declare -- BASH="/bin/sh"

Fix:
I'm clueless.

Re: capturing in ${VAR//(*(\/)(+([^\/]))?(\/)/_${BASH_REMATCH[1]}_}

[Stephane Chazelas]

2016-02-08 09:00:09 -0500, Chet Ramey:
> On 2/8/16 2:47 AM, Linda Walsh wrote:
> > When you are doing a var expansion using the
> > replacement format ${VAR//./.}, is there some way to
> > put parens around some part of the expression and reference
> > them as in the [[V~re]] RE-matches?
> 
> No.  Shell patterns do not have backreferences.
[...]

Note that the feature is available in other shells and quite
handy there. It could be worth adding to bash

$ zsh -o extendedglob -c 'a=1234; echo ${a//(#b)(?)(?)/${match[2]}${match[1]}}'
2143
(#b) to activate back-references stored in $match array.

$ zsh -o extendedglob -c 'a=1234; echo ${a//(#m)?/<$MATCH>}'
<1><2><3><4>
(#m) to record the matched portion in $MATCH.

Though I suspect for bash you would prefer the ksh93 syntax:

$ ksh93 -c 'a=1234; echo ${a//@(?)@(?)/\2\1}'
2143

-- 
Stephane

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Chet Ramey]

On 2/8/16 9:59 AM, Andreas Schwab wrote:
> Chet Ramey  writes:
> 
>> `cd ..' should fail, since the parent no longer exists, and the pathname
>> canonicalization should fail, since there's presumably no longer a valid
>> path to reach the current directory.  No value for $PWD is correct.
> 
> ${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
> this case, it doesn't fail.

Why would that be more reasonable than anything else?  It references a
path that doesn't exist.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

bug when 'cd ..' to a directory who's parent has been deleted

[Odd Beck]

Hi!

When I'm in a folder, and then remove that folder's parent from a different
shell, and I then press 'cd ..', I get an error, and then a weird result in
the path that shows my current directory.

Here's a picture where you can see the weird result.

Best regards

Odd Beck

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Chet Ramey]

On 2/8/16 7:09 AM, Odd Beck wrote:
> Hi!
> 
> When I'm in a folder, and then remove that folder's parent from a different
> shell, and I then press 'cd ..', I get an error, and then a weird result in
> the path that shows my current directory.

It's not clear what you expect to happen.

I'm not sure how you managed to remove the parent directory, since rmdir
doesn't generally allow you to remove a directory that's not empty, but
let's assume that you're in an orphaned directory (one without a parent).

`cd ..' should fail, since the parent no longer exists, and the pathname
canonicalization should fail, since there's presumably no longer a valid
path to reach the current directory.  No value for $PWD is correct.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: capturing in ${VAR//(*(\/)(+([^\/]))?(\/)/_${BASH_REMATCH[1]}_}

[Chet Ramey]

On 2/8/16 2:47 AM, Linda Walsh wrote:
> When you are doing a var expansion using the
> replacement format ${VAR//./.}, is there some way to
> put parens around some part of the expression and reference
> them as in the [[V~re]] RE-matches?

No.  Shell patterns do not have backreferences.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Andreas Schwab]

Chet Ramey  writes:

> `cd ..' should fail, since the parent no longer exists, and the pathname
> canonicalization should fail, since there's presumably no longer a valid
> path to reach the current directory.  No value for $PWD is correct.

${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
this case, it doesn't fail.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Chet Ramey]

On 2/8/16 10:57 AM, Andreas Schwab wrote:
> Chet Ramey  writes:
> 
>> If you assume, as the OP said, that only the parent is removed, it's
>> unlikely.
> 
> You cannot remove a non-empty directory, so this does not make sense.

And so we return to the first paragraph of my original response.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

manpage question re: '--debugger': what/where is debugger *profile*

[Linda Walsh]

Under the bash-arg "--debugger" it says:

   Arrange for the debugger profile to be executed before the shell
   starts.   Turns  on extended debugging mode (see the description
   of the extdebug option to the shopt builtin below).


When I think of a "profile" in bash, I think of things
like /etc/profile or ~/.{bash_,}profile.

Is there something like that for debugging
(ex: /etc/bash_debugging or ~/.bash_debugging)?

If not, what does it all mean, er, that is
if the only thing it does is turn on the extdebug
option, then what is the 1st sentence talking about
in addition the the extdebug option mentioned in the
2nd sentence?

Re: manpage question re: '--debugger': what/where is debugger *profile*

[Chet Ramey]

On 2/8/16 4:06 PM, Linda Walsh wrote:
> Under the bash-arg "--debugger" it says:
> 
>Arrange for the debugger profile to be executed before the shell
>starts.   Turns  on extended debugging mode (see the description
>of the extdebug option to the shopt builtin below).
> 
> 
> When I think of a "profile" in bash, I think of things
> like /etc/profile or ~/.{bash_,}profile.
> 
> Is there something like that for debugging
> (ex: /etc/bash_debugging or ~/.bash_debugging)?

This refers to the debugger startup file that's installed as part of the
bashdb package.  To use this mode, the bashdb install location has to agree
with the bash define for DEBUGGER_START_FILE.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Chet Ramey]

On 2/8/16 11:34 AM, Linda Walsh wrote:

>> Why would that be more reasonable than anything else?  It references a
>> path that doesn't exist.
>>
>>   
> Um...Not exactly.  As long as there's a handle open to the previous path,
> it still exists (at least on linux and unix).

The actual filesystem objects still exist, but the named references to them
(pathnames) do not.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Linda Walsh]

Dave Rutherford wrote:



On Mon, Feb 8, 2016 at 11:34 AM, Linda Walsh > wrote:

>> Why would that be more reasonable than anything else?  It references a
>> path that doesn't exist.
> Um...Not exactly.  As long as there's a handle open to the previous path,
> it still exists (at least on linux and unix).

Really?
11:40:24 dave@Vger:~$ mkdir -p a/a
11:40:30 dave@Vger:~$ cd a/a
[remove a in another window]
11:40:49 dave@Vger:~/a/a$ touch file
touch: cannot touch ‘file’: No such file or directory



Yes!  Really.  You and Andreas have to read what was written.

Pretty much the same setup as you have, but I'm using an "fd" to
the previous path. Are you using an "fd" in your example, I seem
to be missing it.

Ish:lw> ll a
ls: cannot access a: No such file or directory
Ish:lw> mkdir -p a/a
Ish:lw> cd a/a
Ish:lw/a/a> cp /tmp/filesave.txt file.txt
Ish:lw/a/a> ll
total 4
-rw-rw-r-- 1 415 Feb  8 13:39 file.txt
Ish:lw/a/a> rm -f /tmp/ctl; Delayed_save_file_via_fd  ...Reading...

[ Other term>
Ish:lw> rm -fr "a/" ; echo -e ~/a/a/file.txt\\n.\\n >/tmp/ctl
] Original term:

saved 415 bytes in file "file.txt", dir "/home/lw/a/a"
cd "$PWD"
[1]+  Exit 1  Delayed_save_file_via_fd /tmp/ctl < file.txt
Ish:lw/a/a> ll
total 4
-rw-rw-r-- 1 415 Feb  8 15:16 file.txt

Delayed_save_file_via_fd is attached.




Andreas Schwab wrote:

You cannot have handles on file names, only on files.

---
I said:
"As long as there's a handle open to the previous path..."


You can't open a file handle on a file.  The fd comes from some
OS call associating it with the file on disk (or some other connection).

Not only that, but you can **run** from those deleted paths --
the kernel says the "fd" is associate with deleted path:

Ish:lw/a/a> cp /usr/bin/sleep .
Ish:lw/a/a> ll
total 48
-rw-rw-r-- 1   415 Feb  8 15:16 file.txt
-rwxr-xr-x 1 41676 Mar  2  2015 sleep*
Ish:lw/a/a> sleep 999&
[1] 41987
Ish:lw/a/a> cd ../..
Ish:lw> rm -fr a
Ish:lw> deleted_procs

Deleted programs  Pid(s)
-- --
/home/lw/a/a/sleep41987


Looks like a path to me.  Will attach "deleted_procs" too.




#!/bin/bash -u

#include stdalias
shopt -s expand_aliases
alias sub=function my=declare
alias int='my -i'  string=my  intConst='my -ir' array='my -a'

export 
PS4='>${BASH_SOURCE:+${BASH_SOURCE[0]/$HOME/\~}}#${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}>
 '

shopt -s extdebug

my cd=$PWD
int tries=-1
string h1="" h2=""
intConst EPERM=1 EINVAL=22 ENOTDIR=20
int verbose=0


sub inf () {
(($#)) || return 0
int newline=1
if [[ $1 == "-n" ]]; then newline=0; shift; fi
(($#)) || return 0
my out=""
printf -v out "$@"
if ((newline)) && [[ ${out:0-1} != $'\n' ]]; then
out="$out"$'\n'
fi
printf >&2 "%s" "$out"
((verbose)) && sleep .1
return 0
}

sub err () {
int stat=$EINVAL
if (($#)); then
if [[ $1 =~ ^[-0-9]+$ ]]; then
stat=$1; shift
fi
if (($#)); then
inf "$@"
else
inf 'Err status=%d\n' "$stat";
fi
return $stat
else
return 0
fi
}

sub get_sp() {

while [[ ! -f $control ]];do sleep 1; echo -n . ;  done
while [[ ! $savepath ]]; do
read -t 1 inp  <"$control"
if [[ $inp ]]; then
if [[ $inp != . ]]; then
savepath=$inp
fi
break
fi
done

[[ ${savepath:0:1} != / ]] && savepath="$cd$savepath"
}

sub get_content () {
inf -n "Reading..."
while read inp;do
my out=""
printf -v out '%s\n' "$inp"
content+=( "$out" )
content_len+=${#out}
done
}



sub saveworker() {
my control=${1:?"need place to get fn"}
array content=()
int content_len=0
my inp="" savepath=""
string h1=""
string h2=""

get_sp

((verbose)) && inf 'Got save path as:%s' "$savepath"

get_content

((verbose)) && inf 'Attempting to save %d lines (%d chars) in %s\n' \
"${#content[@]}" "$content_len" "$savepath"

my d=${savepath%/*}
my f=${savepath##*/}

while [[ ! -d $d ]]; do
if ((tries+=1)); then
inf 'Attempting to REcreate %s\n' "$d"
fi
mkdir -p "$d/.hold"
int mstat=$?

if ((!mstat)); then h1="$d/.hold"
else
err $mstat "Cannot mkdir -p %s" "$d/.hold"
return $?
fi
if ! cd "$d" ; then
err