zdotdir

zdotdir

[Yuri D'Elia]

I recently decided to move all my config files (.zshrc, .zprofile, etc)
to ~/.zsh/, so in my ~/.zshenv I set:

ZDOTDIR=~/.zsh

However, I would like then the files not to have a leading dot, so I
could just have

~/.zsh/zprofile like in /etc/.

Is it possible?

Re: zdotdir

[Aaron Kaufman]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

You can use 'source' to source any file name.

For example: source $HOME/.zsh/zprofile and so on.
I hope that helps.
On Mar 10, 2014 4:55 AM, "Yuri D'Elia" <wavexx@thregr.org> wrote:

> I recently decided to move all my config files (.zshrc, .zprofile, etc)
> to ~/.zsh/, so in my ~/.zshenv I set:
>
> ZDOTDIR=~/.zsh
>
> However, I would like then the files not to have a leading dot, so I
> could just have
>
> ~/.zsh/zprofile like in /etc/.
>
> Is it possible?
>
>

Re: zdotdir

[Yuri D'Elia]

On 03/10/2014 01:01 PM, Aaron Kaufman wrote:
> You can use 'source' to source any file name.
> 
> For example: source $HOME/.zsh/zprofile and so on.
> I hope that helps.

The only hook I have I zshenv, I cannot source the other files and get
the same effect from there.

Re: zdotdir

[Bart Schaefer]

On Mar 10, 12:51pm, Yuri D'Elia wrote:
}
} However, I would like then the files not to have a leading dot, so I
} could just have
} 
} ~/.zsh/zprofile like in /etc/.
} 
} Is it possible?

Just create symbolic links:

cd $ZDOTDIR
for dotfile in zshenv zshrc zprofile zlogin; ln -s $dotfile .$dotfile

If for some reason you don't want to use symlinks, you can instead do

cd $ZDOTDIR
for dotfile in zshenv zshrc zprofile zlogin
  print "source \$ZDOTDIR/$dotfile" > .$dotfile

but that will print errors about missing files if you don't create all
four of the dot-less ones, which the symlink approach will not.

Re: zdotdir

[Yuri D'Elia]

On 03/10/2014 04:32 PM, Bart Schaefer wrote:
> Just create symbolic links:
> 
> cd $ZDOTDIR
> for dotfile in zshenv zshrc zprofile zlogin; ln -s $dotfile .$dotfile
> 
> If for some reason you don't want to use symlinks, you can instead do
> 
> cd $ZDOTDIR
> for dotfile in zshenv zshrc zprofile zlogin
>   print "source \$ZDOTDIR/$dotfile" > .$dotfile
> 
> but that will print errors about missing files if you don't create all
> four of the dot-less ones, which the symlink approach will not.

Not fancy, but will do ;)
Thanks, didn't think about this.

return up two levels?

[Ray Andrews]

Didn't I read somewhere that one can return from a function 'up two 
levels'? i.e. that if function1 calls function2, that function2 can 
return both itself and function1? I have a helper function that might 
want to return to the calling function, or might want to return right 
back  to the shell. Of course I can do this with with return value tests 
within the calling function, but it would be nice if the helper function 
could handle it internally. Is it possible? 'exit' kills the shell 
itself, so it's too aggressive.

Re: return up two levels?

[Peter Stephenson]

On Mon, 10 Mar 2014 11:25:23 -0700
Ray Andrews <rayandrews@eastlink.ca> wrote:

> Didn't I read somewhere that one can return from a function 'up two 
> levels'? i.e. that if function1 calls function2, that function2 can 
> return both itself and function1?

function1() { function2; print Doesn\'t get called; }
function2() { trap 'return' EXIT; print Does get called; }


% function1
Does get called


Of course you can return at the point you set the trap, I'm just
illustrating that the forced return of the parent function isn't tied to
the child function returning immediately.

And regardless of options EXIT traps are only associated with the
immediate parent, so...


function0() { function1; print Does get called, too; }


% function0
Does get called
Does get called, too


So forcing a whole hierarchy to return immediately is harder work.  You can set an exit trap inside an exit trap, if you want (I haven't tried but I have a vague memory of debugging this years ago), but it gets messy.

pws

Re: return up two levels?

[Ray Andrews]

On 03/10/2014 12:42 PM, Peter Stephenson wrote:

Peter:
> function1() { function2; print Doesn\'t get called; }
> function2() { trap 'return' EXIT; print Does get called; }
Thanks, that about does it. I've not used traps up till now.

BTW I'm enjoying  your book. Hats off to Oliver as well of course.

Re: return up two levels?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Please don't use that technique unless it's in the context of something
atypical like a debugger. It's a really bad software pattern. It's spooky
action at a distance. It's a form of monkey-patching. it practically
guarantees hard to debug errors. Plus a large number of other problems.
Don't do it. Be explicit about return values. If you want a caller of
function2 to exit immediately have function2 return non-zero and test for
that. For example,

function2() { print I failed to do my job; return 1 }
function1() { if ! function2; then; print unexpected failure; return 0; fi;
print life is good }



On Mon, Mar 10, 2014 at 8:00 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 03/10/2014 12:42 PM, Peter Stephenson wrote:
>
> Peter:
>
>> function1() { function2; print Doesn\'t get called; }
>> function2() { trap 'return' EXIT; print Does get called; }
>>
> Thanks, that about does it. I've not used traps up till now.
>
> BTW I'm enjoying  your book. Hats off to Oliver as well of course.
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: return up two levels?

[Ray Andrews]

On 03/10/2014 08:33 PM, Kurtis Rader wrote:
> Please don't use that technique unless it's in the context of something
> atypical like a debugger. It's a really bad software pattern. It's spooky
> action at a distance. It's a form of monkey-patching. it practically
> guarantees hard to debug errors. Plus a large number of other problems.
> Don't do it. Be explicit about return values. If you want a caller of
> function2 to exit immediately have function2 return non-zero and test for
> that. For example,
>
> function2() { print I failed to do my job; return 1 }
> function1() { if ! function2; then; print unexpected failure; return 0; fi;
> print life is good }
>
Hmmm, sobering advice. I'm always looking to expand the techniques 
available to me,
and Peter's 'trap' idea does/would streamline my code for this one 
particular problem,
which is just a very short helper function called in almost all of my 
other functions  in
a trivial and routine sort of way where there are unlikely to be any 
strange issues. Still, this
trap thing violates the rule of least surprise and breaks the basic 
rules of code flow, so
I do take your point.  I guess if this sort of thing can be considered 
'standard zsh practice'
then I'm inclined to keep it, but if not, then out it goes.  But all the 
'sh's' have so many
abominable and dirty practices anyway that this trap would hardly stand 
out ;-)