Wikipedia:Reference desk/Archives/Computing/2021 March 30

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 30

bash filename completion in the presence of shell variables

It's not uncommon for me to type something like

cp $var/dir1/dir2/partia

and then hit the Tab key to complete that partial filename there at the end. This has been working fine for years. Recently, though (after an upgrade), the behavior changed. Now, the Tab key still autocompletes as much as it can, but it also helpfully sticks a \ before the $. So I might end up with something like

cp \$var/dir1/dir2/partial.

Now, there are two problems here:

1. If I type, say, an additional c and then the Tab key again, hoping to progress the completion to partial.cpp, it doesn't work, because the $ is now quoted, so the shell is no longer autocompleting filenames in $var/dir1/dir2 any more, and
2. In any case, the eventual actual cp command won't work at all, because of course there is no such directory $var with a literal $ in its name; I wanted $var to be expanded.

I appreciate that bash is trying to make it easier for me to refer to files and directories with literal $'s in their names (which I do, of course, approximately never), but really, I'd rather eschew that protection and have it leave the $'s alone. I assume there's an option to turn this behavior off. Anybody know what it is? This is bash version 5.0.3(1), if it matters. —Steve Summit (talk) 20:44, 30 March 2021 (UTC)

Does this help? https://nelsonslog.wordpress.com/2012/01/29/bash-4-2-variable-expansion-bug/ Dalek Supreme X (talk) 04:10, 31 March 2021 (UTC)

@Dalek Supreme X: Yes, it helped a lot, thank you very much!

The referenced page describing a patch of Chet Ramey's doesn't seem to exist any more, but I found some bash documentation which describes the mentioned shell option direxpand which does just what I want.

(Although the behavior without direxpand is annoying and rather useless, it's also true that the behavior with direxpand is sort of alarmingly strange at first, so I can understand the desire to not have it on by default, even though it's exactly what you probably want.)

What's odd is that this is evidently a rather old issue, so I'm surprised it only bit me this month. I'm guessing that the most recent distro I installed changed direxpand to not be on by default any more, or something. —Steve Summit (talk) 15:54, 31 March 2021 (UTC)

Write through secondary cache

I am setting up a 486 PC for DOS / Windows 3 retrogaming. I also want to boot Linux but I haven't got that working yet.

It has a clock quadrupled 133 MHz 486 (33MHz external bus) with 16KB of write-back level one CPU cache.

This feeds into a slower 1MB level two cache (a bunch of socketed DRAM chips) which then feeds the even slower 256MB main memory.

My question is about the level two cache. It can be configured to write-through cache all 256MB (using 8 bits for the tag RAM) or to write-back cache the lower 128MB (using 7 bits for the tag RAM and 1 dirty bit).

The two benchmark the same, because the games I am using to do the test pretty much always hit the 16KB cache on the CPU and don't end up using over 128MB of main memory. But which configuration is theoretically better? I am pretty sure Linux will be able to make good use of the larger main memory.

Here is my thinking. Tell me if I am wrong.

For reading memory, the bigger cacheable maim memory wins. Fewer cache misses, fewer trips to the slower main memory.

For writing memory, I think the writes always hit the 16MB CPU cache and allow the program to quickly move on to the next instruction. If I am correct, write-back on the level two cache simply speeds up something that the CPU never sees.

Thus I conclude that write-through secondary cache of the entire 256MB beats write-back secondary cache of the lower 128MB. Am I right? Dalek Supreme X (talk) 21:11, 30 March 2021 (UTC)

The cache working for the full memory will be always better unless you limit Linux to using only 128 Mb of the RAM. Ruslik_Zero 19:27, 31 March 2021 (UTC)

Thanks! --Dalek Supreme X (talk) 22:51, 31 March 2021 (UTC)

You're correct that a write always goes to L1 cache. But, if there's a write miss and L1 is full, it has to evict an entry first, and the CPU has to wait on that. The evicted entry gets written to L2, and if the value is an L2 write hit with write-back, there's no waiting on a write to RAM. --47.155.96.47 (talk) 00:19, 1 April 2021 (UTC)

That would explain my benchmark results under DOS. with a 1MB cache and an OS that uses 640KB max the L2 is never full but the L1 can be. Dalek Supreme X (talk) 16:01, 2 April 2021 (UTC)