Hello:

Being a long time user of Nvidia legacy cards/drivers under Linux, I was interested in seeing what smxi was about and saw that the author is also the author of the inxi script.
Did not know that.

Although inxi is in the Devuan repositories, I see that smxi (or the other author's scripts) is not.
Further looking in https://pkginfo.devuan.org/ revealed that it smxi has never been included in any Devuan repository.

Is there a specific reason for that?

I have read posts from mid 2015 regarding some difficulty the smxi script seemed to have ID'ing Devuan but it seems to have been fixed.

EDIT:
Fix confirmed - https://github.com/smxi/inxi/blob/master/inxi.changelog

Thanks in advance,

A.

Some time ago, the world+dog endlessly busted Torvald's balls because he shouted and cursed a number of dimwitt/AH coders in order to keep a tight ship.
But it does not seem that anyone is saying absolutely anything about this nonsense.

Call me what you will, but I think that if this type of thing is not stopped ASAP, the Linux kernel as we know it will end up going to the dogs.

A.

Hello:

Finally found a clue here:
https://askubuntu.com/questions/103913/ … l-commands

The solution is within ~/.bashrc, where you have to edit this section of the script ...

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    #alias grep='grep --color=auto'
    #alias fgrep='fgrep --color=auto'
    #alias egrep='egrep --color=auto'
fi

... to get this:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=always'
    alias dir='dir --color=always'
    alias vdir='vdir --color=always'
    alias grep='grep --color=always'
    alias fgrep='fgrep --color=always'
    alias egrep='egrep --color=always'
    alias dmesg='dmesg --color=always'
fi

Basically what this is does is generate aliases with the --color=always modifier.

From what I have read in the link, it would seem that the --color= modifier is hard coded into dmesg as well as other utilities.
eg: apparently dir does not have it but ls does.

Cheers,

A.

Hello:

Yes, that did it.

That too ...
But then I realised that a label could end up not being as unique as a UUID.

Thanks a lot for your input.

Cheers,

A.

Hello:

Thank you for pointing that out in such a gentle manner.
Should know better by now, must make it a point of looking through the man files before asking.  =-7

I'll have a good look at that and see if I can replace auto with always. 

I'll check that out also.

Thanks a lot, you have been very helpful.

Cheers,

A.

Hello:

Sorry for reviving an oldish thread but I just came across your post.
These days I seem to have more time to read unanswered posts ....   =-/

One of the things I like of how Devuan ascii is implemented is how console output is highlighted at boot time and when using commands such as dmesg.
Unfortunately, the output of dmesg | grep whatever gets written to the terminal without any highlighting.

Is there a way to fix/change this so that anything printed to the terminal has the same highlighted output/behaves in the same manner, irrespective of whatever comes after the command line instruction?

It would be nice to have it enabled by default.

Thanks in advance,

A.

Hello:

Yes, but ...

Samsung_M2020_Series groucho 3 [27/Nov/2018:16:41:51 -0300] 1 1 - localhost
Samsung_M2020_Series groucho 3 [27/Nov/2018:16:42:00 -0300] 2 1 - localhost
Samsung_M2020_Series groucho 4 [05/Dec/2018:08:29:39 -0300] 1 1 - localhost
                             | <- print job  page number -> | | <- pages printed

In the example above, we see two print jobs: print job 3 which outputs 1 copy of page 1 and 1 copy of page 2 and print job 4, which outputs 1 copy of page 1.
The awk stanza in my previous post will correctly tally the amount of pages printed, ie: 3 pages.

groucho@devuan:~/Desktop/awkcups$ awk '/groucho/{pages += $7} END {print pages}' /home/groucho/Desktop/awkcups/plog1
3
groucho@devuan:~/Desktop/awkcups$ 

Now, in a different scenario, where we have two digit print jobs with the rest being the same ...

Samsung_M2020_Series groucho 13 [27/Nov/2018:16:41:51 -0300] 1 1 - localhost
Samsung_M2020_Series groucho 13 [27/Nov/2018:16:42:00 -0300] 2 1 - localhost
Samsung_M2020_Series groucho 14 [05/Dec/2018:08:29:39 -0300] 1 1 - localhost

... the awk stanza previously applied gives an incorrect output, ie: 5 pages 

groucho@devuan:~/Desktop/awkcups$ awk '/groucho/{pages += $7} END {print pages}' /home/groucho/Desktop/awkcups/pg1log
5
groucho@devuan:~/Desktop/awkcups$ 

The same problem would arise if a print job is for 20 copies of a single page.

At the risk of stating the obvious, the same awk stanza parses the /var/log/cups/page_log file which (depending on how the printer is used) can have between one and four digits both in the print job number and the number of pages printed. I limit this to four digits because the size of cartdrige 2020W cartdrige won't ever print 9999 pages.   

I can't see how to solve this with awk and have searched all over the web for a script to do basic CUPS accounting to no avail.

Thanks for your input.

A.

Hello:

Yes, but thenI'd be running trim every time I booted the rig, which could be up to three or four times a day.

I'm looking to analyse the /var/log/trim files in a month or so to see what went on and then decide on weekly, monthly or something else.

There's a chap that wrote a daemon for running trim here:

https://github.com/dobek/fstrimDaemon

He argues that it would seem to be "more reliable to execute fstrim based on up time then cron table.".

Thanks for your input.

Cheers,

A.

Hello:

Right. (A bit late in life but I have vowed to try to stop using OK)

I see.

Hmm ...
I'll start looking again to see if I can find out just where it comes from.

I was just about to do that when I found trimmed_log.txt.

--- solved ---

From its content and name, it seemed (to me) that it could have been produced by fstrim.
But it turns out that it is not.   =-)

A search on the web brought up just three hits, one of them from a thread I (!) started here at Dev1.
So it turned out that it was right in front of me/us.

See here:
https://dev1galaxy.org/viewtopic.php?pid=20206#p20206

And here:
https://dev1galaxy.org/viewtopic.php?pid=20211#p20211

It was generated when I was trying to figure out how many pages my M2020W cartdrige had actually printed before running out.
Which I still have to figure out how to awk properly.

Thanks a lot for your input.

Cheers,

A.

Hello:

I posted and went to make myself an espresso which made my head work a bit better.

So:

groucho@devuan:~$ locate trim
/home/groucho/trimmed_log.txt
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man3/malloc_trim.3.gz
/usr/share/man/man8/fstrim.8.gz
/usr/share/tools/trim26lst
groucho@devuan:~$ 

Seems that the fstrim util is in/part of the Devuan ascii distribution.
And from the locate printout, it also seems that it has been run before.

groucho@devuan:~$ cat /home/groucho/trimmed_log.txt
[30/Nov/2018:10:44:10-0300] 1
[08/Dec/2018:19:12:32-0300] 1
--- snip ---
[17/Feb/2020:13:44:14-0300] 1
groucho@devuan:~$ 

The trimmed_log.txt (which for some strange reason is not in /var/log) only gives date, time and what would be the trim (?).

But ...

I only installed the SSD yesterday, no SSDs before that, so fstrim was working on some other drive.
I speculate that it was on the SAS drive replaced with the Kingston SSD ie: boot drive. (?)

Q:
1. How is fstrim set up and started? 
2. Will it keep working now albeit on the SSD?

Some dates in /home/groucho/trimmed_log.txt are far apart and there are up to 30 entries with the same date (with trims as high as 24 so it does not seem to be a cron job.

So if it is not a cron job, what triggers it to run and how can it be modified?

Thanks in advance,

A.

Hello:

I don't think it is the case here.

Yes, I had read something about that.

I'll see if I can find if there is a utility that can log swap activity (I think I saw one once ...) over a set amount of time, say 30/60/120 days and evaluate the results.
I have enough relatively fast SAS 3.0Gb/sec rust so I could eventually set up an 8.0Gb swap partition on one of them.

Thanks for your input.

Cheers,

A.