Re: shell script problem
On Wed, Feb 06, 2019 at 02:22:35PM +0900, John Crawley wrote: > On 06/02/2019 03.17, ghe wrote: > > On 2/5/19 9:19 AM, Jude DaShiell wrote: > > > Have you tried replacing "-" with \45 yet? That's the ascii equivalent > > > for "-'. > > > > Excellent idea. But: > > > > root@sbox:~# systemctl unmask \45.mount > > Unit 45.mount does not exist, proceeding anyway. > > > > (Same with quotes.) > > > You might try > root@sbox:~# systemctl unmask $'\45'.mount > Just a thought. You're all just making stuff up without understanding it. First of all, the ASCII value of - is 45 decimal, or 055 octal, or 0x2d hexadecimal. If you use bash's $'\...' quoting syntax, you get to choose between octal and hexadecimal, the default being octal. So, $'\055' is equivalent to '-'. $'\45' is a percent sign. Second, whatever form of quoting you use in your shell command is simply a mechanism to make sure your intended arguments get passed to the command you're invoking. Once the shell has parsed your quoting, the quotes are removed. The command doesn't see them. As arguments, - and "-" and '-' and $'-' and $'\055' and $'\x2d' are all exactly the same. There is no difference at all. wooledg:~$ args - "-" '-' $'-' $'\055' $'\x2d' 6 args: <-> <-> <-> <-> <-> <-> The command (mount, umount, systemctl unmask, or whatever) does not know or care which kind of quoting, if any, you used in your shell. This is also why the classic Unix shell FAQ "how do I remove a file whose name starts with -" is such a puzzler for many people. People think that by quoting the leading - they will somehow make rm treat it as a filename instead of an option. But because of how shells *work*, the quotes are removed, and rm has no idea that you quoted it. Answer to the FAQ: you must tell rm that this argument is a filename and not an option. You do that by putting the end-of-options indicator -- before the filename. E.g. rm -- -myfile Another way to do it is to give rm a pathname that does not begin with a - character. E.g. rm ./-myfile The latter only works because the argument to rm *is* a pathname, and relative pathnames can have a leading ./ prepended to them without changing their meaning. Now, I don't know how systemctl unmask works. You can try putting -- before your unit argument, if the unit name truly begins with a -, and see if that helps. Or, you can try to figure out whether this is really the correct unit name at all. It seems rather dubious. Is there any chance that your fstab file is simply malformed, and is being converted into bogus .mount units? Maybe you should go through your /etc/fstab and look for errors.
Re: shell script problem
On Wed, Feb 06, 2019 at 02:04:54AM -0800, Rusi Mody wrote: > I seem to be missing something... > Is -.mount literally a thing? > Or -- more likely -- are shell's arcane quoting/interpolating rules garbling > something quite into a "-" unit? Perhaps you're better off looking into the systemd config directories and finding out what symlinks point to /dev/null or something (no systemd expert here, though). Cheers -- t signature.asc Description: Digital signature
Re: shell script problem
I seem to be missing something... Is -.mount literally a thing? Or -- more likely -- are shell's arcane quoting/interpolating rules garbling something quite into a "-" unit?
Re: shell script problem
On 06/02/2019 03.17, ghe wrote: On 2/5/19 9:19 AM, Jude DaShiell wrote: Have you tried replacing "-" with \45 yet? That's the ascii equivalent for "-'. Excellent idea. But: root@sbox:~# systemctl unmask \45.mount Unit 45.mount does not exist, proceeding anyway. (Same with quotes.) You might try root@sbox:~# systemctl unmask $'\45'.mount Just a thought. -- John
Re: shell script problem
On 2/5/19 2:05 PM, Greg Wooledge wrote: >> I still think that that massive effort might have been better spent >> fixing init. Handling threads, tightening some methods and regulations, >> tidying up init.d and its buds, [...] > > Start here: https://jdebp.eu/FGA/system-5-rc-problems.html Yup. The init startups and such were, indeed, at best bent. So fix them. There's something to be said for sticking with Thompson and Ritchie's thoughts when developing *nix. They were smart, thoughtful guys. -- Glenn English
Re: shell script problem
On Tue, Feb 05, 2019 at 02:00:12PM -0700, ghe wrote: > I still think that that massive effort might have been better spent > fixing init. Handling threads, tightening some methods and regulations, > tidying up init.d and its buds, [...] Start here: https://jdebp.eu/FGA/system-5-rc-problems.html
Re: shell script problem
On 2/5/19 12:01 PM, Greg Wooledge wrote: >>From man systemctl: > >mask NAME... >Mask one or more units, as specified on the command line. This will >link these unit files to /dev/null, making it impossible to start >them. This is a stronger version of disable, since it prohibits all >kinds of activation of the unit, including enablement and manual >activation. Use this option with care. This honors the --runtime >option to only mask temporarily until the next reboot of the >system. The --now option may be used to ensure that the units are >also stopped. This command expects valid unit names only, it does >not accept unit file paths. Yeah, I saw that. So mask is stronger that whatever disable is. And it 'prohibits all kinds of activation of the unit' -- but it, apparently, encountered a masked unit, notified me, them just went on with the script. I've seen error messages saying ' but going on anyway'. Nothing like that in this case, but it did go on anyway. Apparently. This adventure has made me believe that systemd was a massive effort. But also that there are some areas where it could still use a little work. I still think that that massive effort might have been better spent fixing init. Handling threads, tightening some methods and regulations, tidying up init.d and its buds, enabling startups in PERL, Python, Ruby, C, Java, etc. -- things legible and debuggable. Maybe even shell, if you're into a syntax from the late 1940s... -- Glenn English
Re: shell script problem
Okay so "-" isn't a systemd unit name. At this point, you might do well to examine dmesg. Check for fatals errors and warnings and see if any interesting material turns up. On Tue, 5 Feb 2019, ghe wrote: > Date: Tue, 5 Feb 2019 13:17:49 > From: ghe > To: debian-user@lists.debian.org > Subject: Re: shell script problem > Resent-Date: Tue, 5 Feb 2019 18:18:34 + (UTC) > Resent-From: debian-user@lists.debian.org > > On 2/5/19 9:19 AM, Jude DaShiell wrote: > > > Have you tried replacing "-" with \45 yet? That's the ascii equivalent > > for "-'. > > Excellent idea. But: > > root@sbox:~# systemctl unmask \45.mount > Unit 45.mount does not exist, proceeding anyway. > > (Same with quotes.) > > --
Re: shell script problem
On Tue, Feb 05, 2019 at 11:51:42AM -0700, ghe wrote: > I'd still like to know what 'mask' means in systemd. >From man systemctl: mask NAME... Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the unit, including enablement and manual activation. Use this option with care. This honors the --runtime option to only mask temporarily until the next reboot of the system. The --now option may be used to ensure that the units are also stopped. This command expects valid unit names only, it does not accept unit file paths.
Re: shell script problem
On 2/5/19 9:12 AM, john doe wrote: > What message Never mind. It quit complaining. No changes to the scripts. Maybe a systemd update -- there are several updates to lots of code with testing. Thanks for the responses. > In general, ignoring error messages is a recipe for disaster. You'd think so. Usually, though, they aren't just kidding... I'd still like to know what 'mask' means in systemd. And what a '-.mount' is. -- Glenn English
Re: shell script problem
On 2/5/2019 7:17 PM, ghe wrote: > On 2/5/19 9:19 AM, Jude DaShiell wrote: > >> Have you tried replacing "-" with \45 yet? That's the ascii equivalent >> for "-'. > > Excellent idea. But: > > root@sbox:~# systemctl unmask \45.mount > Unit 45.mount does not exist, proceeding anyway. > > (Same with quotes.) > $ systemctl status -- -.mount -- John Doe
Re: shell script problem
On 2/5/19 9:19 AM, Jude DaShiell wrote: > Have you tried replacing "-" with \45 yet? That's the ascii equivalent > for "-'. Excellent idea. But: root@sbox:~# systemctl unmask \45.mount Unit 45.mount does not exist, proceeding anyway. (Same with quotes.) -- Glenn English
Re: shell script problem
On 2/5/2019 4:43 PM, ghe wrote: > Buster > > A shell script has begun to throw errors I can't seem to get rid of. > Didn't used to -- it started in the past few days. > > I have access to a couple Internet connections: a slow but extremely > reliable T1 I've been with for years, and a Comcast residential cable > WiFi that's odd, but very fast. There are 2 Ethernet ports on the box. > > I wrote a shell script for the frequent and large Buster updates, etc. > that brings up the Comcast WiFi, makes changes in the DHCP info, > modifies the routing table so the mirrors in the sources list are routed > through Comcast, and fires off aptitude. > > The problem is that toward the end of bring up Comcast, I get a message > from systemd saying '-.mount is masked'. The systemd man pages say there > is indeed something called -.mount and that being masked will kill any > process encountering a masked something. The message says it's going to > quit the script. > What message? > Then it goes on with the script, and as best I can tell, finishes properly. > > The man pages say there is a way to unmask things (I can't remember what $systemctl unmask > it is). When I run the command, I'm told that the parameter is wrong (it Which cmd? > doesn't like the '-', understandable). I put it in quotes, same thing. I > try it with something else masked in the list, and it comes back with > the expected *nix response when all is well (nothing). But when I look > at the list again, it's still masked. > > What's going on? What does 'masked' mean? What is '-.mount'? Should I > just ignore the error message? Can I ignore any systemd error message? > - What's going on -- can't say without seeing the script in question and the error message you're getting. In general, ignoring error messages is a recipe for disaster. -- John Doe
Re: shell script problem (was: Re: [OT] rearranging data files)
On Sat, Jun 08, 2002 at 07:14:03PM +0200, Jörg Johannes wrote: | Hm. | | If | ./col2row.sh | gives Keine Berechtigung, but this one works: | sh ./col2row.sh | | then you most likely put the script on a filesystem that has been | mounted with the noexec attribute. Sometimes people mount /tmp this | way. Another test of this would be to copy /bin/ls to the same location | and trying ./ls. | | (Note that mounting a filesystem with noexec does nothing for security, | as it is easily overcome) | | Using /bin/sh (or /bin/ksh or /bin/bash) shouldn't really matter here; | although I have only really tested it with bash (my /bin/sh is a symlink | to /bin/bash). | | Hello Karl | | I can't try out at the moment (I'm not at my own box now), but a noexec | mounted filesystem should not be the cause for this issue. I could run the perl | and python scripts just this way. Any other idea? What does Keine Berechtigung mean? Is it literally Permission Denied? If so, try chmod u+x ./col2row.sh and run it again. Also make sure the script starts with a correct #! line. -D -- For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power plants that only _look_ like they would keep all the radiation inside. (Scott Adams - The Dilbert principle) GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpmEHE6ynJmR.pgp Description: PGP signature
