Menu
▾
▴
psh-dev
|
From: Amokrun <am...@ma...> - 2003-01-05 08:17:15
|
I didn't find a mention about this problem, but apologies if this has already been asked or is only an error on my side. When doing random 'cd' commands, sometimes psh refuses to find the directory. Yet, if you type it again, chances are it will be found. Here's what happened to me on linux, when I tried to repeatedly type the same command in /. psh% cd .. psh% cd .. psh% cd .. psh% cd .. psh% cd .. psh: ..: No such directory. psh% cd .. psh% cd .. psh: ..: No such directory. psh% cd .. psh% cd .. psh% cd .. psh% cd .. psh: ..: No such directory. psh% cd .. psh% At no point did the directory change, and obviously the .. does exist or doesn't exist in each case. However, the behaviour is completely random. This also happens with real directories, so sometimes trying to back out of /home will result in error, and sometimes trying to type 'cd /home' will fail, telling the directory doesn't exist. It also happens with just 'cd', so the target doesn't matter. If this is simply something I did wrong, could someone explain where the error could be in? This happens with the newest release (1.0) on linux. I can't think of anything I did that would result in such random behaviour. In fact, it's out-of-the-box version, I didn't do anything but install it. -- ,+[-->++++[>++++++++<-]<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<] >>[ === Unfortunately nobody can be told what the === -]> >-- ================ ma^H^H rot13 is ================ [-[ >-<[-]]]>+[-<+++++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<] >[-] ======= You have to try it out yourself ======= >[-] +>[<-->-[<+>-]]<[<<<<+++++++++++++>>>>-]]<<[-]<<+.[-]<,+] |
|
From: Markus P. <wa...@sp...> - 2003-01-06 13:42:32
|
--On Sonntag, 5. Januar 2003 14:00 Uhr +0200 Amokrun <am...@ma...> wrote: > I didn't find a mention about this problem, but apologies if this has > already been asked or is only an error on my side. > > When doing random 'cd' commands, sometimes psh refuses to find the > directory. Yet, if you type it again, chances are it will be found. > Here's what happened to me on linux, when I tried to repeatedly type the > same command in /. I have to admit, I'm pretty clueless. I never had experienced such problems myself and I fear without being able to reproduce, I cannot do something about it. Would it be possible you investigate a bit more into the problem yourself, so that you could maybe find out, what happens under the hood for the denied directory change requests? -- Markus Peter - SPiN AG wa...@sp... |
|
From: Amokrun <am...@ma...> - 2003-01-06 15:33:38
|
> > I didn't find a mention about this problem, but apologies if this has > > already been asked or is only an error on my side. > > > > When doing random 'cd' commands, sometimes psh refuses to find the > > directory. Yet, if you type it again, chances are it will be found. > > Here's what happened to me on linux, when I tried to repeatedly type the > > same command in /. > > I have to admit, I'm pretty clueless. I never had experienced such problems > myself and I fear without being able to reproduce, I cannot do something > about it. > > Would it be possible you investigate a bit more into the problem yourself, > so that you could maybe find out, what happens under the hood for the > denied directory change requests? Ok, here's the drill so far. 1. It does correctly attempt to use cd each time. Thus, the issue is within the code for 'cd' or in something that 'cd' uses. 2. The error is "can't find", not "can't access". Thus, from what I learned about the code in 5 minutes of reading, it goes all the way past the block for checking the directory existence. Only way to generate that error is if the prior loop fails and the execution goes all the way to the end. 3. This is not a problem with my system. In fact, all 3 other versions of psh I tested worked fine. Also, in fact, this same problem happens on another machine. It also isn't a problem in the system level, since no other shells for example repeat such behaviour. 4. It is irrelevant what the original directory is, as well as what directory you attempted to enter. It can happen with anything in anywhere, so it's a global problem, not just something related to certain patterns. 5. It's completely random. You can get 50 successes in a row, then get 10 errors. No logic that I can explain seems to be associated. From what I can tell, the system for 'cd' command is totally different from the last version. It used to be in a large library, now all these are separated into individual files. Also, a dir stack of some sort is now used. Since the structure for the code seems to be more or less identical on the major parts compared to the old, my only good guess is that it has something to do with the stack system, which is the only major addition since the last version. Since I haven't read most of the code, it was impossible to tell where the problem is. My best guess is the new changes and the stack type, but I haven't read the code yet. I'll do it as soon as I get enough time. It's hard to start when you have no idea how the program is designed in general. However, since the older version works just fine, and I the new version doesn't add anything which is of much importance for me, I should be fine with using it for now. If I can figure out what is causing this, I'll post it here. -- ,+[-->++++[>++++++++<-]<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<] >>[ === Unfortunately nobody can be told what the === -]> >-- ================ ma^H^H rot13 is ================ [-[ >-<[-]]]>+[-<+++++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<] >[-] ======= You have to try it out yourself ======= >[-] +>[<-->-[<+>-]]<[<<<<+++++++++++++>>>>-]]<<[-]<<+.[-]<,+] |
|
From: Markus P. <wa...@sp...> - 2003-01-06 16:16:58
|
--On Montag, 6. Januar 2003 21:16 Uhr +0200 Amokrun <am...@ma...>
wrote:
> Ok, here's the drill so far.
>
> 1. It does correctly attempt to use cd each time. Thus, the issue is
> within the code for 'cd' or in something that 'cd' uses.
First one more question: Do you have the environment variable CDPATH set or
not?
As far as I can see, the failure occurs with using "cd ..". Taking your
description into account, this means the cd stack system cannot be the
culprit, as it's not even called.
Could you maybe add a little patch to your psh version to get some debug
output?
Please add the following line to lib/Psh/Builtins/Cd.pm:
print STDERR "$dir\n";
This line should go to line 76 of Cd.pm, just in front of the
if( $dir and (-e $dir) and (-d _)) {
Afterwards, you have to install and run your test again (start using
"psh -d1" - this will enable further debug messages) and please email me a
transcript of the session (only the part where you tried the cd's - the
output will be rather long probably with full debuging enabled).
This helps us locate whether the problem is in calculating the abs_path of
the dir or somewhere later.
Thanks for your help!
--
Markus Peter - SPiN AG
wa...@sp...
|
|
From: Amokrun <am...@ma...> - 2003-01-06 16:54:48
|
> > 1. It does correctly attempt to use cd each time. Thus, the issue is > > within the code for 'cd' or in something that 'cd' uses. > > As far as I can see, the failure occurs with using "cd ..". Taking your > description into account, this means the cd stack system cannot be the > culprit, as it's not even called. It's irrelevant what the directory was. It can happen with "cd /home" or just about anything I tested. Which leads to the next thing . . . > > Could you maybe add a little patch to your psh version to get some debug > output? From what I tested, this is what happens when you keep repeating it. Keep in mind that the exact command doesn't matter, and I only used "cd .." because it was easy to type repeatedly and you should never get anywhere by doing it, so the situation is always the same, thus it should always behave in same way. ================= psh% cd .. [Using strategy built_in: cd] debug: / [repeat last message] psh% cd .. [Using strategy built_in: cd] debug: psh: ..: No such directory. psh% cd .. [Using strategy built_in: cd] debug: / ================= It seems like it somehow gets empty $dir instead of '/', which was the current directory. This is also true in other cases, I quickly tested it by going back and forth between few directories. When it failed, the result was same, empty directory. Thus, I can understand why it fails. What I don't get is why it happens on totally random logic. > Afterwards, you have to install and run your test again (start using > "psh -d1" - this will enable further debug messages) It seems that both -d and -d1 give equal debug in this case. > This helps us locate whether the problem is in calculating the abs_path of > the dir or somewhere later. Well, the reason why it fails is now obvious. Reason for why it sometimes runs with empty directory isn't all that clear to me. As for other details, I tried to run the shell without .pshrc file, with one with least amount of changes possible, with various variables as well as on two different systems. None of these had any effect on the outcome, so it shouldn't be a configuration issue. > Thanks for your help! Thanks for your shell, as well as time. -- ,+[-->++++[>++++++++<-]<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<] >>[ === Unfortunately nobody can be told what the === -]> >-- ================ ma^H^H rot13 is ================ [-[ >-<[-]]]>+[-<+++++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<] >[-] ======= You have to try it out yourself ======= >[-] +>[<-->-[<+>-]]<[<<<<+++++++++++++>>>>-]]<<[-]<<+.[-]<,+] |
Thanks for helping keep SourceForge clean.
X