# pacman -S \$(pacman -Qsq 66serv | grep -v \"boot-66serv\")

Is this command meant to reinstall the installed -66serv from the testing repository and replace the ones from observice?

All I get is an error

# pacman -Qsq 66serv | grep -v \"boot-66serv\"
has the same output as pacman -Qsq 66serv

??
  • [deleted]

- man pacman
-Q : Query the package database ... Additionally, various filters can be applied on the package list
[Query Options]
-s : Search each locally-installed package for names or descriptions that match regexp
-q : Show less information for certain query operations

- man grep
-v : Invert the sense of matching, to select non-matching lines


I have no idea what your are doing to get an error.
pacman -S $(pacman -Qsq 66serv | grep -v "boot-66serv") works as expected.
Compare that to the command I wrote above, the one that is written on the instructions, and the one you wrote.
I know what it is meant to do, but it didn't do it when you just copy the ready made command from the news.sh
I have no idea what your are doing to get an error
One of us must be right not both.
Your command is as it appears when you run # sh news.sh
My command appears when you edit or cat news.sh

I didn't expect formatting to be in the middle of a command and I am not that familiar with sh format syntax, so I included / into the commands, thinking you guys must know better.

And of course if you take all the commands and make a custom script to run this then things go "haywire".
to be displayed correctly with new.sh , some character need to be escaped with bash
the '$' and '"' are this case, that's why you got the backslash when you copy the command.
so if you copy the line and keep the '\' the command go on error because you escape something that it not expected to be escaped.
If you want to make a copy paste use the html format.
The obnews is made to be sure to warm user. It not expected to be copied as it.
But you're behavior here is interesting and remember me (again) to never thrust an user :p

Actually is not a bug, it do what it need to do. In this case the bug come from you lol

EDIT : And of course if you take all the commands and make a custom script to run this then things go "haywire".
That's really a bad idea to make an transition by automatic script without testing it by hands before because you add layer on top of the transition which can be content bug. In your case the service will not be replaced by the one coming from the testing repo and so yes when make a reboot the things go wrong.
But an another problem is coming:
you make bug reports without specifying that you add an extra layer to the instructions :/. How i can know what you do and what you don't do? I can check my instructions again and again and again and see if all goes well. At this state when the things goes like i expect it i can tell:"follow this instructions and the things should go well(can be sure 100% obviously)".
But if you apply the instructions with modifications on it , you should, at least, warn me about that...
I only run the script once on an installation I use for tests. Then I repaired it by following step by step.
I had to come up with a smaller document of instruction and avoiding skipping any steps.
The steps of backing up old stuff (I assume just in case transition doesn't work you can go back, but that is not that simple either) except for the sysadmin/service/files can be skipped. The rest is just updating, dealing with boot.conf, init.conf, etc.
It seems the transition is much simpler and easier done through chroot to the installation, then you just boot to new boot root etc. trees. But it can't be a generic script that works on everyone, each one would have to produce their own. That is the trick.

There is nothing that is not fixable just takes a little more work sometimes. In this case it takes a little more studying.

Powered by Obarun