[SOLVED] One file of every type that is guaranteed to be in every distro?

fatmac · 09-23-2023, 04:25 AM

If you haven't used it, maybe 'file' will help, see 'man file'.

https://linux.die.net/man/1/file

rempas · 09-23-2023, 05:43 AM

Quote:

Originally Posted by fatmac

If you haven't used it, maybe 'file' will help, see 'man file'.

https://linux.die.net/man/1/file

It will help, but I'll also have to run a minimal disto (like I was advised) to make sure that there isn't something that I have installed, and it existed in the system. Thank you for your help, have a great day!

boughtonp · 09-23-2023, 07:25 AM

Quote:

Originally Posted by rempas

I do understand your point and it is true.

If you understand and agree, you wouldn't still be saying you need to do it.

Quote:

However, in my case, I NEED to depend on external files and there is no other way.

There is: have the tests use existing standard tools, not files - arguably still a dependency, but it's a controlled one with defined behaviour.

For example, "mkdir" will always create a directory - whether called as program or a syscall, on any distro - you'll get a directory, not a text file or a symlink or a socket. That is something that is never going to change.

Likewise, "stat" for getting file status, has defined behaviour, and thus is safe to use to test whether the library is creating files correctly.

(This is assuming there's even a reason to create a new library with such functionality, rather than directly using the existing library.)

Quote:

However, things like "lib/libc.so" and "/dev/fd" will probably never move, so I'm fine. But again, if they do, I can always update the test suit.

If you intend to use libc.so you already need to update the test suite, because it's in three different locations on the three distros I checked, and none of them are at "/lib/libc.so"

For something that needs to work on all distros, the location of files is not something that can be guaranteed - one never know when the whims of Red Hat and/or Lennart Poettering will shift.

Quote:

If you are a programmer (which, based on your knowledge about test-suits, I suppose you are), I can give you detailed information about what I'm trying to do

There are plenty of programmers here, particularly in the programming section, and many of them have far more experience with C and systems programming than I do.

Before describing what you're doing, it might be a good idea if you report your first post and ask the moderator to move the thread to the programming section.

jmccue · 09-23-2023, 08:00 AM

Quote:

Originally Posted by rempas

Well, I do write tests suits for my functions and I want to make sure that low level code works.

I doubt you will find a distro with every single possible file type. IIRC, some types are only found on say Windows.

One thing to try is something like this:

Code:

while test "$g_count" -lt 2000
do
    dd if=/dev/urandom of=file.$g_count count=1 bs=64
    g_count=`expr "$g_count" + 1`
done

The larger the max (2000) the better chance of getting some odd file types.

This will at least generate some file types that should not exist on a UN*X, for example, when I executed this it created dummy files of these types:

80386 COFF executable
SysEx File - E-mu
Dyalog APL version 96 .-114
PARIX object
very old 16-bit-int little-endian archive

Most of the files created where tagged as 'data', but at least you will get some files types that I doubt you will find on a UN*X type system.

Good Luck

rempas · 09-23-2023, 08:02 AM

Quote:

Originally Posted by boughtonp

If you understand and agree, you wouldn't still be saying you need to do it.

There is: have the tests use existing standard tools, not files - arguably still a dependency, but it's a controlled one with defined behaviour.

For example, "mkdir" will always create a directory - whether called as program or a syscall, on any distro - you'll get a directory, not a text file or a symlink or a socket. That is something that is never going to change.

Likewise, "stat" for getting file status, has defined behaviour, and thus is safe to use to test whether the library is creating files correctly.

I didn't think about that, this will do the job, thank you! I was actually so focused on my tests and doing it from the suit itself that I didn't think that I can invoke these commands from the shell, so I don't have any problems. Funny enough, I should have thought about it given the fact that I do something similar with Environment Variables... *insert facepalm emoji*.

I guess no matter how hard I try, I remain dumb...

Quote:

Originally Posted by boughtonp

(This is assuming there's even a reason to create a new library with such functionality, rather than directly using the existing library.)

I'm creating a new programming language and I don't want to depend on Libc, so I'm making my own language. It's also practical because I don't like Libc's API for so many things. So yeah, I have to do all this stuff! And I do appreciate everyone's help!

Quote:

Originally Posted by boughtonp

If you intend to use libc.so you already need to update the test suite, because it's in three different locations on the three distros I checked, and none of them are at "/lib/libc.so"

For something that needs to work on all distros, the location of files is not something that can be guaranteed - one never know when the whims of Red Hat and/or Lennart Poettering will shift.

Yeah, I'll use your way to do it! You are completely right, it will be a waste of time and very annoying to trying to do what I was originally trying to do...

Quote:

Originally Posted by boughtonp

There are plenty of programmers here, particularly in the programming section, and many of them have far more experience with C and systems programming than I do.

Before describing what you're doing, it might be a good idea if you report your first post and ask the moderator to move the thread to the programming section.

I was originally planning to keep it as simple as the first post, and I wasn't intended to make it a programming related question, so that's why I posted here. But people asked and well, I gave the details! But I will edit after this reply cause thanks to you, I have the solution!

I haven't noticed (tho I rarely use the forums tbh) the programming thread tho, so this will come very useful in the future! You did 2 great things for me today, thank you a ton!!!! I wish you to have a beautiful day!

rempas · 09-23-2023, 11:40 AM

Quote:

Originally Posted by jmccue

I doubt you will find a distro with every single possible file type. IIRC, some types are only found on say Windows.

One thing to try is something like this:

Code:

while test "$g_count" -lt 2000
do
    dd if=/dev/urandom of=file.$g_count count=1 bs=64
    g_count=`expr "$g_count" + 1`
done

The larger the max (2000) the better chance of getting some odd file types.

This will at least generate some file types that should not exist on a UN*X, for example, when I executed this it created dummy files of these types:

80386 COFF executable
SysEx File - E-mu
Dyalog APL version 96 .-114
PARIX object
very old 16-bit-int little-endian archive

Most of the files created where tagged as 'data', but at least you will get some files types that I doubt you will find on a UN*X type system.

Good Luck

Thank you for the idea and the wise! Thankfully, the comment above you gave me the perfect solution that works and is guaranteed to work. I wish you to have a wonderful day, my friend!

michaelk · 09-23-2023, 12:23 PM

Most file types that are not generic text or data have a specific signature known as a magic number. This is why linux does not care about extensions (in most cases). To create a dummy file of a know data type in most cases you can just add the magic number to the beginning of the file. Since these tend to be binary files/signatures you will need a hex editor to create the specific file type.

https://en.wikipedia.org/wiki/List_of_file_signatures

Much easier then trying to randomly create a specific file type.

rempas · 09-23-2023, 01:58 PM

Quote:

Originally Posted by michaelk

Most file types that are not generic text or data have a specific signature known as a magic number. This is why linux does not care about extensions (in most cases). To create a dummy file of a know data type in most cases you can just add the magic number to the beginning of the file. Since these tend to be binary files/signatures you will need a hex editor to create the specific file type.

https://en.wikipedia.org/wiki/List_of_file_signatures

Much easier then trying to randomly create a specific file type.

When I do say file type, I actually mean REAL file type. These "magic numbers" are assigned to regular files to give them a fake "type" that other programs can read and recognize the file.

Take a look here! Let me know if you have any question I can help with! If not, thank you for your time and have an amazing day!

dugan · 09-23-2023, 06:46 PM

For the record, we know what a file type is and we know what a function is. What we don't know is why you think you think that hardcoding a file path of each type would be useful.