Hidden file interpreted as an improper extension

jfk · 2020-04-10 20:34:11

My .xinitrc file is now interpreted as a type of audio file "audio soundtracker Amiga". Nothing serious but I'd like to know whether we can do something about it.

Apparently the extension .xi is linked to Amiga weirdly conflicting with the hidden function of files grammar. I looked for MIME editors but as I got it they don't allow to change the relationship between the extension and a type of file.

Thanks

Last edited by jfk (2020-04-10 20:35:27)

Slithery · 2020-04-10 20:36:46

There is no relation between extension and file type. Extensions are irrelevant in linux.

jfk · 2020-04-10 20:41:18

OK but you understood what I'd like to achieve. How would you solve that?

jasonwryan · 2020-04-10 21:07:03

"Interpreted" by what?

Trilby · 2020-04-10 21:36:41

jfk wrote:

OK but you understood what I'd like to achieve

I'm not sure about anyone else, but I certainly don't have a clue what you are trying to acheive. Notably, the following doesn't make any sense:

jfk wrote:

... conflicting with the hidden function of files grammar.

There is no hidden function, and files' grammer ... there is no grammar.

I gather that some program is trying to do something with your .xinitrc because that program assumes it is an audio file. That's really all you've given us. What program is behaving incorrectly, and what exactly is it doing that you'd like to change?

jfk · 2020-04-10 22:06:51

OK let me rephrase (I'm not a native).

What I meant by "hidden function of files grammar" is just how files managers display or not a file when a dot is placed before the name of the file.

There is a "conflict" because this way of handling files display is the same way for files association managers to read the type of the file. Thus, as it is the case in my situation, it's possible for the dot to have two functions at the same time, "being hidden" and "being a type of file" - namely when a "name" ends up being simultaneously a "type of file".

I simply want to know how I can tell the files association manager to stop telling me that my ".xinitrc" is an audio file without appending for instance a ".xinitrc.txt". Where should I go?

I hope it's clearer.

Thanks

loqs · 2020-04-10 22:08:57

What file manager is this?

Trilby · 2020-04-10 22:25:46

jfk wrote:

... how I can tell the files association manager to stop telling me that my ".xinitrc" is an audio file

What file association manager, and how is it "telling" you this? Are you referring to the icon shown in a file manager? If so, which file manager? If not, then you still need to describe what is actually happening.

jfk · 2020-04-10 22:45:01

loqs wrote:

What file manager is this?

pcmanfm-qt(-git)

Trilby wrote:

What file association manager, and how is it "telling" you this?

File association in LxQt works with XDG and MIME. The GUI is lxqt-config-file-associations

Therefore, in pcmanfm the colon "Type" says that my ".xinitrc" is "audio Amiga" because an app associates ".xi" (according to lxqt-config-file-associations) to "audio Amiga". I mean it's weird.

Last edited by jfk (2020-04-10 22:45:58)

loqs · 2020-04-10 23:24:03

xdg-mime query filetype ~/.xinitrc
file ~/.xinitrc

jfk · 2020-04-11 11:14:40

loqs wrote:

xdg-mime query filetype ~/.xinitrc
file ~/.xinitrc

Interesting, I got 'text/plain' (as it should be) but still 'audio Amiga' in the environment. I guess there's a bug in lxqt-config-file-associations.

Thanks for your replies though.

Lone_Wolf · 2020-04-11 11:22:28

sounds like something in your xinitrc may be off as I get slightly different results.

$ xdg-mime query filetype ~/.xinitrc
text/x-shellscript
$ file ~/.xinitrc 
/home/panoramix/.xinitrc: POSIX shell script, ASCII text executable
$

Trilby · 2020-04-11 13:04:28

No, text/plain is correct. Attempting to put a shebang on the first line will make it register as text/x-shellscript, but that's not actually a shebang, just a comment - there is no reason for it to be in an xinitrc.

Lone_Wolf · 2020-04-12 13:42:56

The default archlinux file in /etc/X11/xinit/xinitirc has that shebang , and it does appear to come from upstream.

Other then that I do think OP is likely facing a bug in pcmanfm-t

loqs · 2020-04-12 14:03:44

@Lone_Wolf see https://gitlab.freedesktop.org/xorg/app … nit.c#L135

#ifndef SHELL
#define SHELL "sh"
#endif

....

static char *default_client[] = {"xterm", "-geometry", "+1+1", "-n", "login", NULL};
static char *clientargv[100];
static char **client = clientargv + 2; 

....

static void
Execute(char **vec)		/* has room from up above */
{
    execvp(vec[0], vec);
    if (access(vec[0], R_OK) == 0) {
	vec--;				/* back it up to stuff shell in */
	vec[0] = SHELL;
	execvp(vec[0], vec);
    }
    return;
}

So xinitrc is started by sh if xinitrc can not be executed.
Edit:
Corrected the hash bang will be used if present and the file can be executed.

Last edited by loqs (2020-04-12 15:57:59)

jfk · 2020-04-13 15:32:19

FYI

After chatting on Github, the installation of

perl-file-mimeinfo

gives me a different outcome, more consistant with what it is displayed

$ xdg-mime query filetype ~/.xinitrc
audio/x-mod

xinitrc being set without shebang

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

exec startlxqt

Last edited by jfk (2020-04-13 15:34:02)

loqs · 2020-04-13 15:47:57

https://github.com/mbeijen/File-MimeInfo/issues/39

jfk · 2020-04-13 16:06:45

loqs wrote:

https://github.com/mbeijen/File-MimeInfo/issues/39

Yeah that's it thank you.

What a weird bug.

Trilby · 2020-04-13 17:03:01

After the installation of perl-*:

jfk wrote:

What a weird bug.

'Bout right.

eschwartz · 2020-04-13 22:22:52

Slithery wrote:

There is no relation between extension and file type. Extensions are irrelevant in linux.

That's actually incorrect. What would be correct would be to say that while on Windows, an extension *is* the file type, on Linux, filetypes are based on probing the file through several mechanisms -- and the shared-mime-info database used by XDG permits you to perform probes based on extension. Extensions can, sometimes, be very useful especially as a tiebreaker between several possible content analyses.

And the /usr/bin/file utility can also emit mimetype strings, but it does so using an internal database unrelated to the shared-mime-info one, which only supports "file magic" (header bytes and other content checks) .

The shared-mime-info standard also permits looking for file magic using the descriptions directly based on file's magic(5), whether that is considered to override the extension globbing if they come into conflict is determined by the relative weights: https://specifications.freedesktop.org/ … 3656681504

Arch Linux

#1 2020-04-10 20:34:11

Hidden file interpreted as an improper extension

#2 2020-04-10 20:36:46

Re: Hidden file interpreted as an improper extension

#3 2020-04-10 20:41:18

Re: Hidden file interpreted as an improper extension

#4 2020-04-10 21:07:03

Re: Hidden file interpreted as an improper extension

#5 2020-04-10 21:36:41

Re: Hidden file interpreted as an improper extension

#6 2020-04-10 22:06:51

Re: Hidden file interpreted as an improper extension

#7 2020-04-10 22:08:57

Re: Hidden file interpreted as an improper extension

#8 2020-04-10 22:25:46

Re: Hidden file interpreted as an improper extension

#9 2020-04-10 22:45:01

Re: Hidden file interpreted as an improper extension

#10 2020-04-10 23:24:03

Re: Hidden file interpreted as an improper extension

#11 2020-04-11 11:14:40

Re: Hidden file interpreted as an improper extension

#12 2020-04-11 11:22:28

Re: Hidden file interpreted as an improper extension

#13 2020-04-11 13:04:28

Re: Hidden file interpreted as an improper extension

#14 2020-04-12 13:42:56

Re: Hidden file interpreted as an improper extension

#15 2020-04-12 14:03:44

Re: Hidden file interpreted as an improper extension

#16 2020-04-13 15:32:19

Re: Hidden file interpreted as an improper extension

#17 2020-04-13 15:47:57

Re: Hidden file interpreted as an improper extension

#18 2020-04-13 16:06:45

Re: Hidden file interpreted as an improper extension

#19 2020-04-13 17:03:01

Re: Hidden file interpreted as an improper extension

#20 2020-04-13 22:22:52

Re: Hidden file interpreted as an improper extension

Board footer