Issue #46 raised the question of license and copyright attribution for the Gentoo image, but I don't see any records for other artwork in this project.

The top-level LICENSE file says GPL-3, but that isn't accurate.

Please add a COPYRIGHT file that tracks, for each externally contributed image:

• Copyright holder(s) of individual artwork
• License of individual artwork
• Reference on the holders & license
• Additional data to satisfy requirements of individual licenses, e.g. CC licenses require marking about derivatives: https://wiki.creativecommons.org/wiki/License_Versions#Modifications_and_adaptations_must_be_marked_as_such

I've tried to build an example using Android for you:

Android

Base artwork:

• Copyright Holder: Google Inc.
• License: CC-BY-3.0
• License-URL: https://creativecommons.org/licenses/by/3.0/
• Reference: https://developer.android.com/distribute/marketing-tools/brand-guidelines#android_robot

Modifications

• Description: uwu style
• Copyright Holder: ???
• License: CC-BY-3.0
• License-URL: https://creativecommons.org/licenses/by/3.0/

Here is the screenshot of terminal

Add support for EndeavourOS if possible :3

Build fails on FreeBSD 12

# gmake build
cc -O3 -o uwufetch uwufetch.c
uwufetch.c:26:10: fatal error: 'sys/sysinfo.h' file not found
#include <sys/sysinfo.h>
         ^~~~~~~~~~~~~~~
1 error generated.
gmake: *** [Makefile:18: build] Error 1

This might be too soon to implement this, but it might be a good idea for uwufetch to generate a config file to be edited and then read when the command is run so that you don't have to enter arguments every time, i.e. setting default behaviours.

Doing this can also simplify things later down the line if more features are added.

UwU~ your p-pwogwam made a fucky wucky, owo!~

Pwease fix this code, senpai!! ^w^

Hi.

As far as I can see, this is a duplicate of #39, but this commit did not resolve the issue.

I think this may be caused by lshw being not installed, hence the GPU name is being detected incorrectly as well (I have a NVIDIA GPU).

When running running make I keep getting the same error

cc -O3 -o uwufetch uwufetch.c
make: cc: No such file or directory
make: *** [Makefile:25: build] Error 127

this goes for make build and sudo make install.
My pc is running artix.

I tried uwufetch and uwufetch-git but both are the same

This is a discussion, not an actual issue.

Recently, UwUFetch started using JSON for the config file using an external library, but I think JSON isn't good for a config file a human would write. Here is why:

1. JSON isn't very readable for humans.
2. It can cause more syntax errors.
3. A config file should be easy to understand and write, without many rules.
4. Need an external library

I think the old approach using a simple KEY=VALUE was better than a JSON file. Here is why:

1. More readable for humans.
2. It's simple to write, so there are not many syntax errors.
3. A custom parser isn't hard to make, no need to use an external library.

EDIT: Spelling errors.

Got this warning when building the last commit.
Full message:

$ make
gcc -O3 -o uwufetch uwufetch.c
uwufetch.c: In function ‘get_info’:
uwufetch.c:180:26: warning: ‘memmove’ reading 64 bytes from a region of size 37 [-Wstringop-overflow=]
  180 |  if (strlen(shell) > 16) memmove(&shell, &shell[27], sizeof(shell)); // android shell was too long, this works only for termux
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Arch Linux (kernel: 5.11.2-arch1-1)
gcc version 10.2.0 (GCC)

This is what happens when I run it:

The CPU model name gets weirdly cut off to just two characters and the GPU model wraps over to the next line, breaking the ASCII art on the left. Font is Terminus and I'm using Konsole if that helps

it would be nice to add support for system information for the Raspberry Pi

A good way to show instructions and some information is in man pages, this is something missing in uwufetch.
The man page could contain some info from README.md (like requisites, LICENSE, image and copyright info).

Man pages can be developed in a lot of different ways, just searching on internet and choose the one you think it's the better.

FreeBSD has a Linux binary layer which works like it runs Linux natively, and uwufetch doesn't seem to recognize it's run from FreeBSD if I run the Linux ELF binary from it.
Is there any way to find out that's it's being run by a compatibility layer?

Here's a picture of what I mean:

As you can see, the 14 Flatpak packages gets included in the (pacman) package count, which is incorrect.

This is only a suggestion, because I'm writing a PKGBUILD for uwufetch and the Arch build system restricts packages from writing to the home folder at install time. This is probably true for other package managers if someone were to create a package for this as well since it would be problematic if resource files were to be available to only the user that installed it while the binary is installed globally.

I noticed that GPU detection without lshw stopped working completely after #45.

Here's the output I get before the merge:

And here's after the merge:

I was wondering if this is intentional, since these lines still exist:
https://github.com/TheDarkBug/uwufetch/blob/57e016e3dcae0301b5c257530ca1a65f9c3cb885/uwufetch.c#L219-L223
Which as far as I can understand is the fallback GPU detection if lshw isn't installed. Correct me if I'm wrong though.

Ok it's a little awkward to submit an issue to my own program.
Anyway if uwufetch is compiled with -O3 or any other optimization it runs with a segmentation fault:

I don't know why is this happening, maybe it has something to do with parsing the config file.

Right now, when trying to use uwufetch -i without viu installed this will show up:

My suggestion is to implement a checking mechanism to see if viu is installed in the system (maybe whereis viu?) and print a proper error message if it's not installed and/or fall back to ascii.

So I ran make on my vps and got the following errors. I'm not sure how to remove this warning though.

uwufetch.c:101:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[1], "%d", &dnf);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:102:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[2], "%d", &emerge);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:103:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[3], "%d", &flatpak);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:104:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[4], "%d", &nix);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:105:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[5], "%d", &pacman);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:106:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[6], "%d", &rpm);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:107:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(file[7], "%d", &xbps);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c: In function ‘get_info’:
uwufetch.c:148:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  fscanf(fos_rel,"%[^\n]", version_name);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:165:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(fcpu, "%[^\n]", cpu_model);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:170:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(whoami, "%s", user);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~
uwufetch.c:173:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(fcpu, "%[^\n]", cpu_model);

I'm experiencing a reliable segfault on a VPS of mine, while running uwufetch from a python program.
I can't reproduce this on my main machine or outside of the python program.
I don't have any idea what the cause could be.

Output of dmesg:

[2296997.676920] uwufetch[602704]: segfault at 0 ip 00007fc7f4fe1f4a sp 00007ffee11ee228 error 4 in libc-2.33.so[7fc7f4ebb000+14b000]
[2296997.677083] audit: type=1701 audit(1632051413.051:55175): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=602704 comm="uwufetch" exe="/usr/bin/uwufetch" sig=11 res=1

output of journalctl:

Sep 19 13:36:53 vbox systemd-coredump[602706]: [🡕] Process 602704 (uwufetch) of user 1000 dumped core.
                                               
                                               Found module linux-vdso.so.1 with build-id: 68f6e36e0fd83223b553b19c82de3c4a799f606e
                                               Found module ld-linux-x86-64.so.2 with build-id: 040cc3dd10461562f177df39e3be2f3704258c3c
                                               Found module libc.so.6 with build-id: 4b406737057708c0e4c642345a703c47a61c73dc
                                               Found module uwufetch with build-id: e2e7629457d789d8a3f0d9784eff69b8075866d1
                                               Stack trace of thread 602704:
                                               #0  0x00007fc7f4fe1f4a __strcpy_ssse3 (libc.so.6 + 0x14cf4a)
                                               #1  0x0000556192861174 n/a (uwufetch + 0x2174)
                                               #2  0x0000556192860256 n/a (uwufetch + 0x1256)
                                               #3  0x00007fc7f4ebcb25 __libc_start_main (libc.so.6 + 0x27b25)
                                               #4  0x000055619286042e n/a (uwufetch + 0x142e)

uwufetch running fine on the same vps:

Another system information that seems like it might be worth adding. I don't exactly know how it would be implemented for different platforms though, but I think it's doable.

I have read the read me today, and saw that uwufetch supports endeavour os. i clean installed uwufetch and it still says "unknown" in OWOS and shows a tux for my distro ascii. How can i fix this?

1. This would allow easier modification
2. Make it easier to specify path to own images

When I try saving the output of uwufetch to a file some information is missing.

Another problem is that the ascii art is above the information it would be great to have it on the left like it gets displayed.

uwufetch-version: 1.4-1 (AUR)
Terminal: Alacritty

Another thing: for some reason uwufetch sometimes prints the text starting on the line of the command. that's why I added the "echo" thing

uwufetch always shows at the top of the terminal instead of just print all information normaly.

Example:
Just some echo and then uwufetch.

Some ls, one neofetch then uwufetch.

While building, it fails with error:
cp: cannot create regular file '/home/(username)/.cache/yay/uwufetch-git/pkg/uwufetch-git/usr/bin/uwufetch': no such file or directory
even if I create it myself, it gets deleted and fails.

I have recent installation of voidlinux and uwufetch is unable to automatically identify the os information.

I checked /etc/os-release file and the issue seems to be here.

Void linux's /etc/os-release file have quotes around void:

# default /etc/os-release for voidlinux

NAME="void"
ID="void"
DISTRIB_ID="void"
PRETTY_NAME="void"

After removing the quotes, i.e., now NAME=void, etc. uwufetch correctly detects the os and displays correctly.

While modifying the /etc/os-release file fixes the issue on the user side for uwufetch. It would be nice if the script can do it correctly. For example, both pfetch and neofetch have no problem detecting voidlinux in either /etc/os-release files with or without the quotes.

Config file:

distro=arch
ascii=true
user=true
os=true
host=false
kernel=true
cpu=true
gpu=true
ram=true
resolution=true
shell=true
pkgs=true
uptime=true
colors=false

Tested on commit 833a223.

I could see this behavior with alacritty and kitty

I propose to add the modified Gentoo logo to the Gentoo Artwork project.
https://github.com/TheDarkBug/uwufetch/blob/main/res/gentoo.png

In order to make this happen a "bug" will have to be filed to the Gentoo bugsystem - https://bugs.gentoo.org/enter_bug.cgi?format=guided

More about the Gentoo's Artwork Project:

• https://wiki.gentoo.org/wiki/Project:Artwork
• https://wiki.gentoo.org/wiki/Project:Artwork/Artwork

Linux 5.10.42-1-MANJARO to Linux 5.10.42-1-MYANJAWO

A lot happened since the last release.

Another thing: If you want you could add the hacktoberfest topic to this repo

It's me with the ram again

After building uwufetch new a new RAM issue came up now I have 0 / 0 MB RAM usage

OPTIONS is never a child of SYNOPSYS.

man renders currently as:

SYNOPSIS
       uwufetch [OPTIONS] [ARGUMENTS]
   OPTIONS

where it should be

SYNOPSIS
       uwufetch [OPTIONS] [ARGUMENTS]

OPTIONS

could you please add xerolinux support? xuwulinux for example

CPU only shows In instead of the proper model name on i3-7020u.

OS: Arch Linux, Build: AUR uwufetch

lshw output for CPU:

*-cpu
          description: CPU
          product: Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz
          vendor: Intel Corp.
          physical id: 4
          bus info: cpu@0
          version: Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz
          serial: To Be Filled By O.E.M.
          slot: U3E1
          size: 714MHz
          capacity: 4005MHz
          width: 64 bits
          clock: 100MHz
          capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d cpufreq
          configuration: cores=2 enabledcores=2 threads=4
        *-cache:0
             description: L1 cache
             physical id: 5
             slot: L1 Cache
             size: 128KiB
             capacity: 128KiB
             capabilities: synchronous internal write-back unified
             configuration: level=1
        *-cache:1
             description: L2 cache
             physical id: 6
             slot: L2 Cache
             size: 512KiB
             capacity: 512KiB
             capabilities: synchronous internal write-back unified
             configuration: level=2
        *-cache:2
             description: L3 cache
             physical id: 7
             slot: L3 Cache
             size: 3MiB
             capacity: 3MiB
             capabilities: synchronous internal write-back unified
             configuration: level=3

uwufetch screenshot:

Maybe im just having trouble finding the docs but im trying to get images to work, i installed vio but i cant find a config file and another issue mentioned that a config file would be placed under ~/.config/uwufetch/config ?

version: latest commit

Shell: zsh
OS: ubuntu on wsl2

When running uwufetch, I'm getting some error:
sh: 1: Syntax error: redirection unexpected
sh: 1: Syntax error: redirection unexpected

If I comment out the 2 popen() lines in get_info(), uwufetch runs without error (although the OS and the CPU aren't displayed).
I tried running both commands in bash and zsh, and it worked without problem.
Pasting those commands into sh indeed raises the same errors as when I run uwufetch, so it seems like popen() is calling sh for me, whatever the original shell I was using.

Examples:

LNVNB161216 Lenovo Legion Y530-15ICH-1060 -> LNVNB161216 Lenowo Legion Y530-15ICH-1060.

Intel Corporation CoffeeLake-H GT2 UHD Graphics 630 -> Intew Copowation CoffeeLake-H GT2 UHD Graphics 630

NVIDIA Corporation GP106M GeForce GTX 1060 Mobile -> NyaVIDIA Copowation GP106M GeFowce GTX 1060 Mobile

This could probably be done with other manufacturers too, in a similar fashion as #107.

0 packages under macOS: #76 (comment)
macOS returns illegal hardware instruction: 938520b

My Ram usage is off by 5gb

~3gb real usage
but 8gb displayed in uwufetch

Running 5.11.10-artix1-1 64bit

paleofetch and fastfetch are way faster than uwufetch.

The command: DATE1=$(date +%s%N) ; uwufetch > /dev/null ; DATE2=$(date +%s%N) ; echo "$(expr $(expr $DATE2 - $DATE1) / 1000000)ms"

I've only tested this with bash, but I have a feeling this happens on other 4-letter shells as well since this doesn't happen with zsh.

too much space between cpuwu and cpuwu name

I am sorry if this is the wrong place to put this but i couldn't find any place else to do so.

I do not currently have the time to add this but something that may help, all someone needs to do is find a way to print it correctly i think. From my findings, there is no standard way to get the GPU name so the way i did it was to use glxinfo and opengl, the command is -> glxinfo | grep 'OpenGL renderer string:' | sed 's/^.*: //' | cut -f1 -d"("

i might be completely wrong but i think this might be your best bet in grabbing the GPU data (probs am wrong tho xD)