sh inxi-master/inxi -GxxSza errors
fm
Status: Interested
Joined: 01 Jan 2019
Posts: 22
Reply Quote
Is there something wrong with inxi that it doesn't like its directory prepended as follows?
:: Code ::
$ unzip master
$ sh inxi-master/inxi -GxxSza
inxi-master/inxi: line 17: use: command not found
inxi-master/inxi: line 18: use: command not found
inxi-master/inxi: line 20: use: command not found
inxi-master/inxi: line 22: syntax error near unexpected token `('
inxi-master/inxi: line 22: `use Cwd qw(abs_path); # qw(abs_path);#abs_path realpath getcwd'
My understanding of shell and scripts is extremely limited.

Here's where it came from:
www.linuxquestions.org/questions/linux-deepin-101/almost-black-screen-after-signing-in-4175664984/
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3946
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Delete whatever you installed, all the files, and install inxi correctly:

as root:

:: Code ::
cd /usr/local/bin
wget -O inxi smxi.org/inxi
chmod +x inxi


Or put sudo in front of each command.

Your problem is corruption somewhere in either your OS or in the inxi file, so first step is to delete everything you downloaded, get rid of the zip master thing, and install inxi.

Those errors means something corrupted either in your system or in the inxi file.

Just because someone wrote some bad directions online doesn't mean you should follow them.
Back to top
fm
Status: Interested
Joined: 01 Jan 2019
Posts: 22
Reply Quote
My own installations have inxi in /usr/local/bin/ since day one of each installation or before. All mine are in multiboot environments with /usr/local/ on a separate filesystem shared by all, and kept current with -U.

As a test after OP's response in that thread I tried the same thing with openSUSE as I suggested the OP do with Deepin and got exactly the same faulty result, so I seriously doubt any kind of corruption was involved other than from my using a poor choice of URL in trying to avoid use of an antique inxi version with a possibly non-working -U switch.

What happened in that thread is a result my attempting to get people to use current inxi instead of an antique provided by a package manager. My habit has been just to linkify inxi with the URL github.com/smxi/inxi, a natural inclination of any non-nerd, fetching directly via a big green download button's URL. What got me started using that URL in these rescue contexts I have no recollection. Now I see the URL I should be using is smxi.org/docs/inxi-installation.htm#inxi-manual-install. I can see looking at it now none of the prominent links there include what other applications typically offer, a GET Appname Now button or link. Whenever that was I probably equated "get" to the page's "github sources", since I knew inxi, rather than a compiled binary, to be a script.

Thank you for inxi and your response.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3946
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
wget -O /usr/local/bin/inxi smxi.org/inxi is a short cut to the github inxi file, that's the correct way to do it. It's simple, clean, and efficient, as long as the user puts it into /usr/local/bin. That's assuming they have a pre 2.9 inxi, otherwise -U is always the correct method for manual updating, unless the distro package for debian/ubuntu was used, in which case you have to override the inxi.conf ALLOW_UPDATE=false

There's no reason to use the github tarball method since it just adds complexity and steps.

If a user's system says 'use' not supported, that's a problem on their system with Perl, nothing else.

github inxi has the steps to install, there is no reason to make up other steps that involve more chance for error, and result in a messier download/extract process.

Since 'use' is a fundamental component of Perl, then there is something wrong with the Perl install on Deepin.
Back to top
Display posts from previous:   

All times are GMT - 8 Hours