backtick usage

[osprey]

Thanks for the information.

Clearly the extended time for the ls command you've described is not a universal problem, but rather a particular problem in a particular case such as your experience. If it was universal, the linux community would have been well aware of it, and it would likely have been fixed very quickly indeed.

If it's a system call issue, discovered from an investigation such as described in post #19, and since system calls involve very low level operations of the kernel at the level of assembly instructions, one could try re-compiling the kernel, or upgrading it. Those are the solutions so far as I see the issue at present. I hope you can get it sorted one way or another.

 

[Diputs]

Thanks for the information.

Clearly the extended time for the ls command you've described is not a universal problem, but rather a particular problem in a particular case such as your experience. If it was universal, the linux community would have been well aware of it, and it would likely have been fixed very quickly indeed.

If it's a system call issue, discovered from an investigation such as described in post #19, and since system calls involve very low level operations of the kernel at the level of assembly instructions, one could try re-compiling the kernel, or upgrading it. Those are the solutions so far as I see the issue at present. I hope you can get it sorted one way or another.

The only thing that gets it fixed is when "Linux" actually fixes it.

It's a widely known issue, and it's easy to reproduce. It's a Linux issue, not necessarily a Kernel issue.

I can only repeat the facts, no matter if people listen to it or not.

I forgot to mention, but a lot of people also like to ignore issues, that's a very widely spread way of working.

 

[osprey]

Hello again Diputs.

In relation to this statement:

It's a widely known issue, and it's easy to reproduce.

it would be helpful if you could provide:

1. some evidence of how widely the problem is known, and,

2. some code or instructions which would reproduce the problem on any linux computer which would allow other users to experience it for themselves.

If the problem is not reliably reproducible on mainstream systems, it's virtually impossible to deal with it and is usually regarded as specific to the context in which it has arisen and thus not a problem for linux generally.

As I understand it, if such a problem was widely known, then it would certainly have been reported in the bug reports about it on the various bug reporting sites of the various distros.

Since the ls command is in the coreutils package, on inspection of the current bugs in that package here:

Bugs in package coreutils (version 9.4-3.1) in unstable -- Debian Bug report logs

there do not appear to be any bugs relating to this particular issue, although there are other bugs mentioned for ls.

In relation to this quote:

It's a Linux issue, not necessarily a Kernel issue.

you may be quite correct that the linux kernel is not responsible for the issue, but since every command such as ls makes a system call of one sort or another, it may be useful and informative to see if there is a system call that is delaying the output of the ls command.

If such a system call can be identified, then one can inspect the source code of the ls command from the coreutils package, perhaps with a debugging program, to see if there is a problem in the code in the way in which ls uses that system call.

As to the other comments in your post #22, I'm not able to validate them.

 

[Diputs]

Hello again Diputs.

In relation to this statement:

it would be helpful if you could provide:

1. some evidence of how widely the problem is known, and,

Try Google or StackExchange dude

 

[Diputs]

there do not appear to be any bugs relating to this particular issue, although there are other bugs mentioned for ls.

That's because you are talking about bugs accepted by the vendor.
I talk about real life, actual bugs.

 

[osprey]

There are a few issues that are unclear to me and that I perhaps don't understand.

In relation to your proposal put in post #20:

If an LS command takes 1 hour, instead of 7 milliseconds, there is no discussion anymore whether or not there is an issue.

the question arose: does the ls command for you take an hour in your case?

The first link you provided in post #20 refers to a delay of ls of just "15-20 seconds", and the responses in that discussion provided on that website are perfectly understandable explanations, with some possible remedies. The discussion there is not identifying bugs, rather providing explanations of the way in which things work.

The second link you provided in post #20 is however not about the ls command at all. Rather it provides a few perfectly good explanations for a delay in the rm command output which are functions of the way the system works rather than any bugs, and they provide the solution to the problem of delay by the use of the xargs program.

Alas, there are some discussions of a slow output for the ls command online, but I couldn't find anything like an hour's delay, and in many cases, the problem was solved because of issues with aliases, color option interferences, bash histories, or if a directory contained files owned by deleted or unrecognised users etc.

In relation to your statement:

you are talking about bugs accepted by the vendor.
I talk about real life, actual bugs.

the reference to the bug reports in post #23 has nothing to do with a "vendor". There is no vendor. The bug reports are submitted by users worldwide in an effort to improve the software, and they are responses to "real life, actual bugs" discovered by users, nothing less. They are reported through the bug reporting system provided, in this case at debian, which is not a vendor, but rather, a community. You could of course submit a bug as well.

I believe I have reached the end of my capacity to assist you on this issue. I had wished for a better outcome, but my limitations have thwarted me. I hope you can resolve your problem with the ls command, and that if you do, you publish the solution.