Computing desk
< January 1	<< Dec \| January \| Feb >>	January 3 >

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.

January 2

bash filename completion constraints

Somewhere on a modern Linux system is embedded the peculiar belief that all sh scripts have filenames ending in .sh. This means that if I have a shell script named, say, shellscriptwithaverylongname, I cannot type

sh shellscr

and hit the TAB key and have it autocomplete. Instead I have to type

xsh shellscr

, then hit the TAB key to have it successfully autocomplete, then type control-A to go back to the beginning of the line, and delete the 'x', then finally hit RETURN.

I'm getting tired of this, so it's time to ask:

What is the bash builtin invocation (I assume it's a bash builtin) that tells bash to limit autocompletion to filenames with the extension .sh if the command is 'sh'?
What system file, likely in /etc, typically contains this sort of filename completion configuration, to be applied to all logins?
Is there an invocation of this or a related bash builtin that can turn off just the constraint for command lines where the command is 'sh', that I could put in my own .bashrc file or the equivalent, if I decide not to modify the system-wide file?

I don't need answers to all three questions; if anyone can answer one I can probably parlay it into answers to the others. Thanks. —Steve Summit (talk) 12:58, 2 January 2021 (UTC)[reply]

Scs, have you tried using bash to invoke the script instead? This works the way you want it. Elizium23 (talk) 13:15, 2 January 2021 (UTC)[reply]

I have not, although (a) I've been typing sh for about 40 years now and my fingers are really used to it, (b) in most cases they are sh scripts, not relying on any bash extensions, so typing bash seems mildly inappropriate, and of course (c) that'd be two more keystrokes! (Also I'm abstractly curious (d) why there is a constraint that sh scripts end in .sh, but there's no such constraint on bash scripts, but that way lies madness, so never mind.) —Steve Summit (talk) 13:56, 2 January 2021 (UTC)[reply]

Scs,

complete -o bashdefault sh
/etc/bash.bashrc is the globally-executed file, and see /etc/skel directory for files which are copied to the home directory of new accounts.
complete -f sh (note: this will use any filename, script or not, as a completion candidate.) Elizium23 (talk) 13:23, 2 January 2021 (UTC)[reply]

Got it. Thank you very much! But now that I know which command to research, I see that complete -r sh is an even closer answer to question 3, so I think I'll use that instead.

Thanks for your detailed (and speedy!) reply. (Thanks, too, for not questioning my admittedly rather curious motives. :-) ) —Steve Summit (talk) 13:56, 2 January 2021 (UTC)[reply]

I make scripts executable, add the shebang line as the first line, and then I don't have to type sh at all. I just type ./myscript... 97.82.165.112 (talk) 16:37, 2 January 2021 (UTC)[reply]

I knew someone was going to suggest that. I do that sometimes, too. (But that wasn't the question.)

Me, I don't even bother with the #! line, or the ./ part of the invocation. (But those weren't the question, either.) —Steve Summit (talk) 00:47, 3 January 2021 (UTC)[reply]

Scs, well, that's a problem. If . is in your path, you have a security hole: any command you type could be intercepted by a malicious (or non-malicious) user with write access to your current working directory. This is particularly dangerous if . is first in the path or if you are running as root. I would strongly encourage you to remove . from your $PATH and get in the habit of using ./ to invoke executables in the current working directory. Elizium23 (talk) 00:54, 3 January 2021 (UTC)[reply]

What exactly do you mean when you say 'if . is in your PATH'? ., (as you know), is the directory you happen to be in at any given time (within your shell session, in its terminal). are you talking about if you happen to be in a directory that happens to be in your PATH while running a script? or are you talking about having a PATH environment that literally includes . in it, so that every directory you are ever in with your shell is always in your PATH no matter what? if its the latter mean....good lord! is that actually?? that is, of course, akin to DOS/Windows behaviour....and is also one of the (many) securtiy design flaws with those OS. :)

but, the OP was running sh followed by the script file...and that wouldnt require . to be in PATH nor use of ./...maybe I missed something though. Firejuggler86 (talk) 05:30, 3 January 2021 (UTC)[reply]

When 97.82.165.112 brought up the possibility of invoking an executable script in the current directory by typing ./myscript, I should not, should not, should not have brought up the possibility of having . in one's path. I knew someone would bring up the well-known security implications, and saying "But those weren't the question, either" was not nearly enough of a hint to head it off. But search paths really are not the question here, so I'm reluctant to delve into them further.

I'm not sure what you mean by "akin to DOS/Windows behaviour", but yes, under Unix-like operating systems you can put . in your search path if you want to, as a simultaneous convenience and security risk. It's generally not (heck, it's just about universally not) recommended, though. See here and here.

If you have a shell script in the current directory, you can run the shell on it with either sh script or sh ./script. (The two are, I think, 100% equivalent.) Or you can make it executable and invoke it with ./script. Or if you have . in your search path (but, yes, again, this is probably a bad idea) you can invoke it with just script.

If a command is not in your current directory then obviously it has to be on your search path if you're going to be able to invoke it just by typing its name. Not as well known is that this is true for scripts as well as commands: If you type sh otherscript and there is no file named otherscript in the current directory, it'll be searched for in all the directories in $PATH, too. —Steve Summit (talk) 16:18, 3 January 2021 (UTC)[reply]

I think Firejuggler86 meant that in cmd.exe in Windows, as in many/most?/all?? variants of DOS before it, the current directory is always searched (by default?) so you can simply type meow and if there is a local file e.g. meow.cmd it will be executed and e.g. 'del / /f /s /q' could happen. You don't have to type ./meow or ./meow.cmd (or .\meow or .\meow.cmd for the Windows/DOS path syntax) as you would have to in most *nixes without . in the path. And as that example demonstrates, for an executable you don't need the extension to execute it, and Windows also lacks an executable flag. The local directory is even generally? searched first, so if some joker puts diskpart.cmd or regedit.cmd in the local directory, you could be in for a nasty surprise especially since you expect a UAC prompt for diskpart and regedit and it isn't that hard to get a UAC prompt from a cmd script. In the unlikely event someone actually types diskpart.exe or regedit.exe, it isn't that hard to make an exe, I chose the cmd example mostly to demonstrate it's extremely trivial. (However commands generally? take precedence, so you can put dir.cmd and expect it to work, unless the person weirdly types dir.cmd.) Given the security risks, Microsoft finally decided to end this default behaviour with PowerShell. Nil Einne (talk) 11:28, 6 January 2021 (UTC)[reply]

kdenlive keeps crashing on Fedora 32 Linux

Per my previous question about video editing on Fedora 32 Linux, I went ahead and installed kdenlive in December. Now I have tried it out, and found out that I can't even get it to start. When I launch it from the start menu, it displays a splash screen, and then crashes. I get a Fedora notification saying kdenlive has crashed and offering to restart it. When I restart it, it crashes again. How can I find out what is going wrong here? JIP | Talk 16:06, 2 January 2021 (UTC)[reply]

JIP, you seem to have a lot of crashy stuff. Have you checked for hardware issues such as bad RAM? Elizium23 (talk) 16:20, 2 January 2021 (UTC)[reply]

Have you tried launching it from a bash window? Check the properties of the menu entry, fire off a terminal window, and run the command. Often, many extra details are revealed. --TrogWoolley (talk) 23:55, 2 January 2021 (UTC)[reply]

Here is what it displays:

"/proc/524775/root"
Invalid metadata for "audiochannels"
Failed to parse "audiochannels"
Invalid metadata for "audioconvert"
Failed to parse "audioconvert"
Invalid metadata for "data_feed"
Failed to parse "data_feed"
Invalid metadata for "imageconvert"
Failed to parse "imageconvert"
Invalid metadata for "telecide"
Failed to parse "telecide"
Invalid metadata for "glsl.manager"
Failed to parse "glsl.manager"
Invalid metadata for "movit.convert"
Failed to parse "movit.convert"
Invalid metadata for "movit.crop"
Failed to parse "movit.crop"
Invalid metadata for "movit.resample"
Failed to parse "movit.resample"
Invalid metadata for "movit.resize"
Failed to parse "movit.resize"
Invalid metadata for "deinterlace"
Failed to parse "deinterlace"
Invalid metadata for "avcolour_space"
Failed to parse "avcolour_space"
Invalid metadata for "avcolor_space"
Failed to parse "avcolor_space"
Invalid metadata for "avdeinterlace"
Failed to parse "avdeinterlace"
Invalid metadata for "swscale"
Failed to parse "swscale"
Invalid metadata for "swresample"
Failed to parse "swresample"
Invalid metadata for "jack"
Failed to parse "jack"
Invalid title/identifier for "crop_detect"
Failed to parse "crop_detect"
qrc:/qml/kdenliveclipmonitor.qml:146:5: Type SceneToolBar unavailable 
         SceneToolBar { 
         ^
qrc:/qml/SceneToolBar.qml:1:1: module "QtQuick.Controls" version 1.4 is not installed 
     import QtQuick.Controls 1.4 
     ^
Segmentation fault (core dumped)

JIP | Talk 02:27, 3 January 2021 (UTC)[reply]

JIP, try sudo apt -y install qml-module-qtquick-controls Elizium23 (talk) 02:34, 3 January 2021 (UTC)[reply]

As I am running Fedora and not Ubuntu, I used dnf instead of apt. Here is the result:

Last metadata expiration check: 2:48:33 ago on Sun 03 Jan 2021 01:47:48 AM EET.
No match for argument: qml-module-qtquick-controls
Error: Unable to find a match: qml-module-qtquick-controls

JIP | Talk 02:37, 3 January 2021 (UTC)[reply]

JIP, it looks like the RPM is named qt5-qtquickcontrols Elizium23 (talk) 02:44, 3 January 2021 (UTC)[reply]

That seems to have worked. I installed it and now kdenlive can at least start up. JIP | Talk 13:32, 3 January 2021 (UTC)[reply]

Do cellular networks use satellite?

When you access the web via a cellphone, the data transfers over radio waves, to a cell tower. Are all cell towers connected via cables, or do some send that information on through satellite?

I'm aware of rural internet providers in Canada using satellite, so I had assumed that they'd also be used for cell data, but I can't find any reference.

I've tried searching Google, but can't find the answer. -- Zanimum (talk) 16:42, 2 January 2021 (UTC)[reply]

At least in reasonably dense environments, individual cell towers are interconnected with microwave links (so you'll see on a typical cell tower a couple of white bass drum-like antennas pointing (horizontally) at other towers. Central office towers will relay this either to long-distance optical fiber or satellite connections. The relatively high latency of sending via a satellite in geostationary orbit means voice communications are (where possible) not routed that way. But satellite communication is easier to provision for remote places. Long distance microwave relay has mostly fallen out of use, but I honestly don't know what places like Russia and Canada do for comms in their hinterlands. -- Finlay McWalter··–·Talk 19:34, 2 January 2021 (UTC)[reply]

You say you tried searching Google. Wikipedia has articles on cellular networks, Satellite phones and Communications satellites.--Shantavira|^{feed me} 10:08, 3 January 2021 (UTC)[reply]

Why aren't satellites used? Communication satellites are geosynchronous. That puts them at about 22,000 miles above the ground. Following major fiber networks from New York to Los Angeles, you can get from one to the other in just over 2,000 miles. On a bad route, you are looking at 3,000 miles. So, it is roughly 10 times the distance to get from the ground to a satellite (which doesn't include the trip back) than it is to go from New York to Los Angeles by fiber. Because the communications are moving very close to the speed of light, you can't improve it by pushing the signal faster. Instead, you have to shorten the distance. You can't have geosynchronous satellites low enough to make them equivalent to fiber. It is only beneficial when there is no connection to use, meaning a very remote tower. 97.82.165.112 (talk) 23:03, 3 January 2021 (UTC)[reply]