Re: Directory completion problems

[Artur Rataj]

~/a$ mkdir .java
~/a$ cd symlink
~/a/symlink$ cd ../.java/
~/a/.java$
~/a/.java$ cd ../
~/a$ rm -r .java && touch .java
~/a$ cd symlink
~/a/symlink$ cd ../.java/
~/.java$

Should it really be like that?

Re: Directory completion problems

[Artur Rataj]

...continuation:

~/.java$ cd ../a
~/a$ rm -r .java
~/a$ cd symlink
~/a/symlink$ cd ../ [now completion does not work]
~/a/symlink$ cd ../.java/
~/.java$

So, cd looks into the logical directory, and if the lookup fails, then it
looks into the physical directory. The cd completion from a symlink,
though, needs a file of a given name in both directories, and it does not
matter if the one in the logical directory is even a directory.

I have a bash style question. Feedback request.

[Steven W. Orr]

I manage a hefty collection of bash scripts. Sometimes, I make heavy use of 
pushd and popd. When problems come up, the directory stack can make debugging 
more complicated than I'd like. One thing I did to get better control over 
things was to write a dstack module that provides pushd and popd functions.


The dstack module gives me simple flags that I can set through an environment 
variable that allow me to dump the stack either before or after a pushd or a 
popd, and to control their stdout and stderr. The default is that they both 
redirect to /dev/null and that all calls are checked when they return. e.g.

push somewhere || die 'Failed to pushd to somewhere'

(I hope people are still reading...)

Recently I discovered context managers in python and I had already implemented 
a directory stack module there. I added a context manager so that instead of 
saying


ds.pushd(foo)
do_a_bunch_of_stuff
ds.popd()

I can now say

with ds(foo):
do_a_bunch_of_stuff
# The popd is now automatic.

Back to bash, I see that things like code readability are impacted by the 
frequent use of pushd / popd. There could be lots (more than a screen full) 
between the pair, and forgetting to put the popd in or losing track of where 
you are can make things more complicateder. So, I thought: How can I get the 
benefit of a context manager in bash? It came to mind that simple curly braces 
might help.


So now I'm thinking of two possible scenarios.

Here's S1:

pushd somewhere
{
do_a_bunch_of_stuff
}
popd

And S2 would be:

{
pushd somewhere
do_a_bunch_of_stuff
popd
}

I'd like to get feedback. Some choices for reasonable feedback might be:
a. It doesn't matter and I'm clearly overthinking this. Just pick one.
b. I like S[12] and anyone who disagrees will be met with a jihad.
c. Here's a better solution that I didn't think of.

If you got this far, have feedback and are in the Boston area, there's a beer 
with your name on it.


TIA :-)

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

Re: I have a bash style question. Feedback request.

[Greg Wooledge]

On Fri, Apr 20, 2012 at 10:38:24AM -0400, Steven W. Orr wrote:
> (I hope people are still reading...)

You'd get a better response on the help-bash mailing list, since you
are not reporting a bug.

Re: I have a bash style question. Feedback request.

[dethrophes]

Am 20.04.2012 16:38, schrieb Steven W. Orr:
I manage a hefty collection of bash scripts. Sometimes, I make heavy 
use of pushd and popd. When problems come up, the directory stack can 
make debugging more complicated than I'd like. One thing I did to get 
better control over things was to write a dstack module that provides 
pushd and popd functions.


The dstack module gives me simple flags that I can set through an 
environment variable that allow me to dump the stack either before or 
after a pushd or a popd, and to control their stdout and stderr. The 
default is that they both redirect to /dev/null and that all calls are 
checked when they return. e.g.

push somewhere || die 'Failed to pushd to somewhere'

(I hope people are still reading...)

Recently I discovered context managers in python and I had already 
implemented a directory stack module there. I added a context manager 
so that instead of saying


ds.pushd(foo)
do_a_bunch_of_stuff
ds.popd()

I can now say

with ds(foo):
do_a_bunch_of_stuff
# The popd is now automatic.

Back to bash, I see that things like code readability are impacted by 
the frequent use of pushd / popd. There could be lots (more than a 
screen full) between the pair, and forgetting to put the popd in or 
losing track of where you are can make things more complicateder. So, 
I thought: How can I get the benefit of a context manager in bash? It 
came to mind that simple curly braces might help.


So now I'm thinking of two possible scenarios.

Here's S1:

pushd somewhere
{
do_a_bunch_of_stuff
}
popd

And S2 would be:

{
pushd somewhere
do_a_bunch_of_stuff
popd
}

I'd like to get feedback. Some choices for reasonable feedback might be:
a. It doesn't matter and I'm clearly overthinking this. Just pick one.
b. I like S[12] and anyone who disagrees will be met with a jihad.
c. Here's a better solution that I didn't think of.

If you got this far, have feedback and are in the Boston area, there's 
a beer with your name on it.


TIA :-)


Tried something like this?


function RunCmdDir {
pushd "${1}" || return $?
"${@:2}"
popd
}
RunCmdDir "Work/Dir" do_a_bunch_of_stuff

ok so you'd have to put the in between code in a function(if you want 
more than 1 instruction) but that would probably help code readability 
anyway.



you could use a sub shell, if do_a_bunch_of_stuff doesn't need to modify 
the global context.

(
cd "Path"
do_a_bunch_of_stuff
)

Re: I have a bash style question. Feedback request.

[Joseph Fredette]

You may be interested in my
version[1]
of a directory stack module. It alters the API a bit from pushd and popd (I
think for the better). And makes use of the subshell techique mentioned by
dethrophes.



[1]https://github.com/jfredett/scripts/blob/master/utilities/dirstack.sh

On Fri, Apr 20, 2012 at 11:13 AM, dethrophes  wrote:

> Am 20.04.2012 16:38, schrieb Steven W. Orr:
>
>  I manage a hefty collection of bash scripts. Sometimes, I make heavy use
>> of pushd and popd. When problems come up, the directory stack can make
>> debugging more complicated than I'd like. One thing I did to get better
>> control over things was to write a dstack module that provides pushd and
>> popd functions.
>>
>> The dstack module gives me simple flags that I can set through an
>> environment variable that allow me to dump the stack either before or after
>> a pushd or a popd, and to control their stdout and stderr. The default is
>> that they both redirect to /dev/null and that all calls are checked when
>> they return. e.g.
>> push somewhere || die 'Failed to pushd to somewhere'
>>
>> (I hope people are still reading...)
>>
>> Recently I discovered context managers in python and I had already
>> implemented a directory stack module there. I added a context manager so
>> that instead of saying
>>
>> ds.pushd(foo)
>> do_a_bunch_of_stuff
>> ds.popd()
>>
>> I can now say
>>
>> with ds(foo):
>>do_a_bunch_of_stuff
>> # The popd is now automatic.
>>
>> Back to bash, I see that things like code readability are impacted by the
>> frequent use of pushd / popd. There could be lots (more than a screen full)
>> between the pair, and forgetting to put the popd in or losing track of
>> where you are can make things more complicateder. So, I thought: How can I
>> get the benefit of a context manager in bash? It came to mind that simple
>> curly braces might help.
>>
>> So now I'm thinking of two possible scenarios.
>>
>> Here's S1:
>>
>> pushd somewhere
>> {
>>do_a_bunch_of_stuff
>> }
>> popd
>>
>> And S2 would be:
>>
>> {
>>pushd somewhere
>>do_a_bunch_of_stuff
>>popd
>> }
>>
>> I'd like to get feedback. Some choices for reasonable feedback might be:
>> a. It doesn't matter and I'm clearly overthinking this. Just pick one.
>> b. I like S[12] and anyone who disagrees will be met with a jihad.
>> c. Here's a better solution that I didn't think of.
>>
>> If you got this far, have feedback and are in the Boston area, there's a
>> beer with your name on it.
>>
>> TIA :-)
>>
>>  Tried something like this?
>
>
> function RunCmdDir {
>pushd "${1}" || return $?
>"${@:2}"
>popd
> }
> RunCmdDir "Work/Dir" do_a_bunch_of_stuff
>
> ok so you'd have to put the in between code in a function(if you want more
> than 1 instruction) but that would probably help code readability anyway.
>
>
> you could use a sub shell, if do_a_bunch_of_stuff doesn't need to modify
> the global context.
> (
>cd "Path"
>do_a_bunch_of_stuff
> )
>
>
>
>
>
>

Re: Why are parameters to Bash's builtin optional?

[Chet Ramey]

On 4/18/12 11:27 AM, Victor Engmark wrote:

>>  I can see printing a list of builtins, though `enable' already does that.
> 
> I guess the difference would be that `builtin` prints *all* builtins, and 
> *never* modifies their state.

What difference does that make?  enable -a prints all builtins, and does
not modify their state unless told to do so.

Why not try out something like the following and see what you
think:

builtin()
{
case $# in
0)  enable -a ; return 0 ;;
*)  command builtin "$@" ;;
esac
}

That might be enough to make it work for you.

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/