Linux file system is unstable

yuri@tsoft.com (Yuri Victorovich) writes:

]> And without details noone will be able to help you.
]> Why is there more than one xprogram in your path? What are they? What
]> are the arguments? etc
]I provided all possible details!
]What difference will it make what the xprogram actually is? It's just
]the shell thing, right?

You admit you cannot figure it out. Why are you then telling us what is
relevant and what not?


]> Note, path IS a shell thing. And if you use setenv then you ARE running
]> csh. And if you use export PATH= then you are running bash.
]I tried both. And both reproduce same problem.

So, tell us exactly what the program is. What is the full path to the
program. What is the output to
whereis xprogram

What is the output of
echo $PATH

What are the two different attepts and the arguments which you claim
shows that the programs run are different.
If the xprogram is a shell script, what is the content of the shell
script.



]> We have to guess because you give no information. While some of us are
]> psychic, the ones who are are on holiday.

]There's ONE BLACK SHELL ONLY. No xterms, no terminal switching.

What is a "black shell" Are you running X? What terminal are you running
if you are running X. If you are not running X, do you mean a console?

What is the output
]Using sh:
]1) mkdir /usr/x
]2) cp ~/xprogram /usr/x
]3) export PATH=/usr/x:$PATH
]4) echo $PATH
]> /usr/x:/bin:/usr/bin:/usr/local/bin
]5) ls /usr/x | grep xprogram
]> xprogram # new one
]6) ls /usr/local/bin | grep xprogram
]> xprogram # old one
]7) xprogram
]> "I am your xprogram"
]8) xprogram "legitimate argument"
]> "What a hell you want ????" # output from /usr/local/bin
]9) /usr/x/xprogram "legitimate argument"
]> "Processing is done" # output from /usr/x/xprogram

Good, now we are getting somewhere.

Is xprogram a shell script or is it a compiled binary program. If it is
a shell script, what is its content.


]-------------
]Now, I don't need answers "You idiot are running it in different
]shells!"
]Because I am not.

]I guess what my question is: is it a known Linux issue having these
]symptoms ??

No.


]As a side-effect: API call "execvp("xprogram", argv)" with the same
]ENV returns "No shuch file or directory" error, but should look up in
]PATH (according to man execvp).

man execvp

The execv and execvp functions provide an array of pointers to null-
terminated strings that represent the argument list available to the
new program. The first argument, by convention, should point to the
file name associated with the file being executed. The array of point-
ers must be terminated by a NULL pointer.


Is it?
Why in the world is there this attempt at secrecy. If you told us what
you actually did, instead of trying to hide it with "xprogram", argv, we
might see somthing you do not. But you are trying desperately to make
sure that we do not get any clue in a case in which you admit to being
clueless, but insist that you know what is relevant and what
irrelevant.\


/tmp/a
#!/bin/bash
echo /tmp/a

/usr/local/bin/a
#!/bin/bash
echo /usr/local/bin/a


string[unruh]> export PATH=/tmp:/usr/local/bin
string[unruh]>a
/tmp/a
string[unruh]>a -g
/tmp/a
string[unruh]>a hogwarts
/tmp/a


Ie, it runs the first program found in the path no matter what the
argument.

(Mandrake 9.1 using bash)



]Yuri

]PS: No ranting, bitching, blameshifting plz

Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
> "Peter T. Breuer" <ptb@oboe.it.uc3m.es> writes:
>>> Using sh:

>>What do you mean by "using sh"? Still, this is better ...

>>> 1) mkdir /usr/x
>>> 2) cp ~/xprogram /usr/x

>>Invalid. Has to be executable with perms +555.

> It would have; for "which" to identify it.

You've clipped too much - I can't follow your discussion here because
it doesn't quote whether he used "which" or not. ANd in particular
you've not noticed that he says "using sh" above (see below for how
this scuppers your commentary).

> cp preserves permissions when possible.

But he didn't mention them at all, as I recall. I can't duplicate his
experiment without knowin them. Not that it matters,because ...

>>Results now depend on whether your shell hashes and caches or not. If
>>this is sh, then you will still get the old one when you call
>>"xprogram", since the location is cached:

> He stated that he did a rehash (csh).

No. See above. He says "using sh".

> csh has "which" built in. It should report consistently with the

I know, and thank you, it's irrelevant, because he says "using sh".

The point is STILL that he doesn't report and observe in sufficient
detail for me to be able to repeat his experiment. When he does, I'll
look at this again.

Peter