antiX community scripts

Forum Forums New users New Users and General Questions antiX community scripts

  • This topic has 16 replies, 9 voices, and was last updated Feb 23-2:13 pm by marcelocripe.
Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #54647
    Member
    marcelocripemarcelocripe

    Translated title: antiX community scripts

    Hello dear colleagues,

    In which directory or folder should I add the antiX community scripts?

    This question of mine occurs, because I am preparing “.zip” packages, where each compressed file will contain: the script “.sh”, the shortcut icon “.desktop” and a text file “.txt” with explanations of how to use it the script and the shortcut icon in graphical mode through the file manager, as well as the command in the terminal to add the new icons in the antiX submenus.

    These scripts and shortcut icons will be properly translated into the Brazilian Portuguese language, with the extremely important collaboration of @PPC in the European Portuguese language, in addition to the extremely important collaboration of @Robin, they will be available in the German, French, Dutch and Russian languages.

    Hopefully, I believe that other people will be interested in using these solutions created by our teachers, teachers and friends who are always developing programs that make using antiX a lot easier. I believe, I agree that other people will collaborate with the inclusion of translations from other languages.

    The other question is, if I include the community scripts in the “/usr/local/bin” folder, if in an antiX update whether these scripts will be deleted because they are not official and because they are in an improper location.

    Currently, I am preparing the scripts and the Exec command path for the shortcut icons directed to the “/home/user_name/.script_name”, but to work on other people’s antiX, you will need to edit the shortcut icons for the name of correct user.

    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    Título original: Scripts da comunidade antiX

    Olá caros colegas,

    Em qual diretório ou pasta devo adicionar os scripts da comunidade antiX?

    Esta minha dúvida ocorre, porque estou preparando pacotes “.zip”, onde cada arquivo compactado conterá: o script “.sh”, o ícone de atalho “.desktop” e um arquivo de texto “.txt” com as explicações de como utilizar o script e o ícone de atalho em modo gráfico através do gerenciador de arquivos, além do comando no terminal para adicionar os novos ícones nos sub menus do antiX.

    Estes scripts e ícones de atalho estarão devidamente traduzidos para o idioma Português do Brasil, com a colaboração extremamente importante do @PPC em idioma Português Europeu, além da colaboração extremamente importante do @Robin, estarão disponíveis nos idiomas Alemão, Francês, Holandês e Russo.

    Esperançosamente, eu acredito que outras pessoas terão interesse em utilizar estas soluções criadas por nossos mestres, professores e amigos que sempre estão desenvolvendo programas que facilitam muito a utilização do antiX. Eu acredito, ainda que outras pessoas irão colaborar com a inclusão das traduções de outros idiomas.

    A outra dúvidas é, se eu incluir os scripts da comunidade na pasta “/usr/local/bin”, se em uma atualização do antiX se estes scripts serão apagados por não serem oficiais e por estarem em um local indevido.

    Atualmente, eu estou preparando os scripts e o caminho do comando Exec dos ícones de atalho direcionados para a pasta “/home/nome_de_usuário/.nome_do_script”, mas para funcionar, no antiX das outras pessoas, será preciso editar os ícones de atalho para o nome de usuário correto.

    marcelocripe
    (Texto original em Português do Brasil)

    #54653
    Member
    AvatarRobin

    Hello Marcelo,

    I’m not quite sure about the best way you could do what you want to achieve.

    I believe there is a way to put new community scripts (standalone ones as well as replacements for standard antiX scripts) alongside to the original ones, without being overwritten by updates. The only important thing is: additional comunity scripts need to be named different from the original ones, they need to be unique. So if you’d like to add a individual replacement for e.g. antixscreenshot.sh, you should better name the individual script antixscreenshot-community.sh instead, which makes it unique and preventing it from being overwritten. Then you need to add an alias for the replacement program only, and both can coexist in system. Please take notice, that the replacement will not get security updates; by standard system update routines as the original does.

    Maybe there is a better solution, e.g. in home folder of the user. So please wait for reactions of the people with the real knowledge about this theme.

    What concerns the translations to any language: It might turn out it will be much easier to use the “standard” way of translating (.mo files) even for community scripts than to rely on the homebrew solution from before. This might be true particularly once the test suite will be completed.
    And what concerns my translations to any other language than German: These are probably urgently in need of being reviewed by native speakers. What I can do is only to translate textstrings thus far their meaning can be understood in the foreign language, so a native speaker not able to read the texts in their original language may improve them.

    Robin.

    • This reply was modified 5 days, 23 hours ago by Robin.
    • This reply was modified 5 days, 23 hours ago by Robin.
    #54729
    Forum Admin
    rokytnjirokytnji

    I just make a folder in /home called scripts and test . Put relevant stuff in there. I do this way before I do the below.

    The other question is, if I include the community scripts in the “/usr/local/bin” folder, if in an antiX update whether these scripts will be deleted because they are not official and because they are in an improper location.

    They won’t be blown away unless they have same name as what is updated. Even then. They are not blown away. Just renamed .old.
    Edit: even during the dist-upgrade process. You are asked a yes or no question on saving configs.
    If AntiX changes system calls that are in your home made scripts in /usr/local/bin.
    Don’t expect them to work then either.

    Usually /opt folder is what you wanna shoot for.

    • This reply was modified 4 days, 21 hours ago by rokytnji.

    Sometimes I drive a crooked road to get my mind straight.
    Not all who Wander are Lost.
    I'm not outa place. I'm from outer space.

    Linux Registered User # 475019
    How to Search for AntiX solutions to your problems

    #54739
    Member
    KooKoo

    Are these scripts available now for download and what do they do. Must admit /usr/local/bin has always been is full of scripting goodness for health and vitality.

    T430 i7-3632QM 16gb , antiX-19.2.1-runit_x64-base Hannie Schaft 29 March 2020 , 5.8.16-antix.1-amd64-smp
    Testing 21a on T430.

    #54743
    Moderator
    Brian MasinickBrian Masinick

    I just make a folder in /home called scripts . Put relevant stuff in there.

    I do something similar; instead of scripts I have /home/Masinick/bin.
    This gives me complete ownership of the tools that I maintain.

    Brian Masinick

    #54745
    Member
    marcelocripemarcelocripe

    rokytnji,

    If I was able to understand the translation of your words well, using the “/opt” folder is better recommended than using the “/usr/local/bin” folder. In this way, official programs are not mixed with non-official programs. The “/opt” folder is where the installation files for google, wine, Office 365 on Electron and other services are stored. Is it recommended to include in the “/opt” folder the executable program files “.AppIamge”?

    Koo,

    The scripts are all created by our colleagues and friends here on the forum, including PPC, Xecure, BobC and many others, masters and teachers of antiX. For now, I don’t know how to create any scripts, just click on the “.desktop” shortcut icons of these scripts for antiX. Most of the time it was PPC that taught me to enter the correct command in the line “Exec =” for the shortcut icon to work. I am translating these scripts into the Brazilian Portuguese language with the help of the internet translators, I venture to try to include the texts in the European Portuguese language (this has several differences in relation to Brazilian Portuguese) and the translation into the English language . If you can help, you will be very welcome, the team will increase … Robin has great skill in several languages, but as he said, it is much better for a native to make the necessary corrections. I don’t know which or which languages ​​do you know? As soon as I can define a free cloud service I will start to send these scripts along with their respective shortcut icon, the text file explaining how to use them, all compressed in a “.zip” file. Later on I will share the URLs to download the files. That way everyone will be able to use the unofficial scripts created by the community and anyone who can help with the translation into other languages ​​will be very welcome.

    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    rokytnji,

    Se eu consegui compreender bem a tradução das suas palavras, utilizar a pasta “/opt” é melhor recomendada de ser utilizada do que a pasta “/usr/local/bin”. Desta forma não é misturado os programas oficiais com os programas não oficiais. A pasta “/opt” é onde vão os arquivos de instalação dos serviços do google, wine, Office 365 on Electron e outros são armazenados. É recomendado incluir na pasta “/opt” os arquivos de programas executáveis “.AppIamge”?

    Koo,

    Os scripts são todos criados por nossos colegas e amigos daqui do fórum, entre eles o PPC, Xecure, BobC e outros tantos, mestres e professores do antiX. Eu, por enquanto, não sei criar nenhum script, apenas os ícones de atalho “.desktop” destes scripts para o antiX. Na maioria das vezes foi o PPC que me ensinou a inserir o comando correto na linha “Exec=” para o ícone de atalho funcionar. Eu estou traduzindo com o auxílio dos tradutores da internet estes scripts para o idioma Português do Brasil, eu me arrisco em tentar incluir os textos em idioma Português Europeu (este possui diversas diferenças em relação ao Português do Brasil) e a tradução para o idioma Inglês. Se você puder ajudar, será muito bem-vindo, a equipe vai aumentando… O Robin possui grande habilidade em vários idiomas, mas como ele mesmo disse, é muito melhor que um nativo faça as correções necessárias. Eu não sei qual ou quais idiomas você conhece? Assim que eu conseguir definir um serviço de nuvem gratuito eu irei começar a enviar estes scripts junto com o seu respectivo ícone de atalho, o arquivo de texto explicando como utiliza-los, tudo compactado em arquivo “.zip”. Posteriormente eu irei compartilhar as URLs para baixar os arquivos. Dessa forma todos poderão utilizar os scripts não oficiais criados pela comunidade e quem puder ajudar com a tradução para outros idiomas será muito bem-vindo.

    marcelocripe
    (Texto original em Português do Brasil)

    #54753
    Member
    skidooskidoo

    if I include the community scripts in the “/usr/local/bin” folder, if in an antiX update whether these scripts will be deleted because they are not official and because they are in an improper location.

    No, non-official files added into /usr/local/bin would not be deleted in bulk.
    However, any file residing in /usr/local/bin which bears the same name as an “official” (provided by an apt -installed package) file, yes, it may be overwritten upon update of the providing package. We can actually prevent (aka workaround) this via use of “dpkg-divert” rules (see “man dpkg-divert” if curious)… but I would not recommend casual use of dpkg-divert. Easier to just avoid the potential problem by choosing non-conflicting filenames.

    /usr/local/bin

    antiX is a “debian -based” operating system.
    Debian policy, uptstream from antiX, spcifies that software packaged by, provided by, debian should never target /usr/local/bin. That path is agreed to be reserved for use by “downstream” local sysadmins.

    Because “antiX is not [exactly] Debian”, as a local sysadmin I am content to find antiX -provided software installed to this path. Opposite from what Dave recently mentioned… instead of pushing existing antiX -provided contents OUT of /usr/local/bin and into /usr/bin (or wherever), I wish all antiX -provided executables NOT currently installed to /usr/local/bin would be moved there. That would make it much easier for me to identify “which commands and scripts are provided by antiX”.

    I have /home/Masinick/bin

    Placement to a path under home would skip the need to involve elevated permissions when installing and maintaining the content. Placement to /opt … installed executables are accessible to all users, but permissions dictate that its content can only be managed|written by root user? (/opt seems attractive only if we envision the target system as a multiuser — multiple login accounts actively utilized — operating system)

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #54755
    Moderator
    Brian MasinickBrian Masinick

    I use my personal bin directory ONLY for personal software. Perhaps I misunderstood the question.

    I agree with skidoo that /use/local/bin ought to be exclusively for antiX software and Debian-sourced software can go in /use/bin.

    As far as any other software, my personal opinion is that ought to be personal choice.

    Brian Masinick

    #54766
    Moderator
    AvatarModdIt

    skidoo wrote: I wish all antiX -provided executables NOT currently installed to /usr/local/bin would be moved there. That would make it much easier for me to identify “which commands and scripts are provided by antiX”.

    Agree, where possible that would be a big improvement.
    Finding antiX scripts is at present a bit like searching for gemstones in darkness. Sad because so many very useful non gui tools are hidden in the depths of the system.

    #54767
    Forum Admin
    anticapitalistaanticapitalista

    We also use apps that originate from MX (but modified for antiX) eg snapshot, codecs installer etc. They go in /usr/bin.
    Basic rule of thumb – antiX scripts including python go to /usr/local/bin and any qt/gtk apps go to /usr/bin or /usr/sbin (following MX’s choice).

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #54770
    Moderator
    Brian MasinickBrian Masinick

    We also use apps that originate from MX (but modified for antiX) eg snapshot, codecs installer etc. They go in /usr/bin.
    Basic rule of thumb – antiX scripts including python go to /usr/local/bin and any qt/gtk apps go to /usr/bin or /usr/sbin (following MX’s choice).

    This is reassuring and reasonable, thanks.

    Brian Masinick

    #54775
    Member
    marcelocripemarcelocripe

    Skidoo, thank you very much for all your explanations.

    Easier to just avoid the potential problem by choosing non-conflicting filenames.

    I will take care to ensure that identical names do not occur.

    I agree with you, it is very good to keep the scripts developed by the antiX team in the “/usr/local/bin” folder, different from the programs coming from Debian in the “/usr/bin” folder. This separation greatly facilitates identification and management.

    I just don’t know if storing in different folders generates some kind of rework for the development team.

    Placement to / opt… installed executables are accessible to all users …

    This information is extremely important to me (thank you!), Because in a multiuser system with multiple accounts, everyone will be able to use the programs, as you explained to me. Does the same rule apply to scripts if they are placed in the “/usr/local/bin” folder? In both folders (“/pt” and “/usr/local/bin”) the management of these scripts needs the powers of the root user (I have already tested them in both folders and needed the root powers).

    As I had previously said the explanatory text files on how to use the scripts, I prepared them with the guidance to put the scripts in “/home/username/.script_name”, that way, only the user in question could use these scripts, similar to that mr. Brian does. But the intention is to allow all users of the same computer to use unofficial scripts created by the antiX community. I will have to edit these callout files and shortcut icons for the new path.

    As some of these scripts have new images that do not exist in antiX, I think it is better to put in /opt, instead of in “/usr/local/bin”.

    Mr. Brian, thank you very much for sharing the information on how you use unofficial scripts.

    As I typed, the ModdIt and anticapitalista made their considerations, thank you.

    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    Skidoo, muito obrigado por todas as suas explicações.

    Easier to just avoid the potential problem by choosing non-conflicting filenames.

    Tomarei os devidos cuidados para garantir que não ocorram nomes idênticos.

    Eu concordo com você, é muito bom manter os scripts desenvolvidos pela equipe do antiX na pasta “/usr/local/bin”, diferenciando dos programas oriundos do Debian na pasta “/usr/bin”. Esta separação facilita muito identificação e o gerenciamento.

    Eu só não sei se armazenar em pastas diferentes gera algum tipo de retrabalho para a equipe de desenvolvimento.

    Placement to /opt … installed executables are accessible to all users …

    Estas informações são importantíssimas para mim (muito obrigado!), pois em um sistema multiusuário com várias contas, todos poderão utilizar os programas, conforme você me explicou. A mesma regra serve para os scripts se forem colocados na pasta “/usr/local/bin? Em ambas as pastas (/opt e /usr/local/bin) o gerenciamento destes script precisam dos poderes do usuário root (eu já testei em ambas as pastas e foi preciso dos poderes de root).

    Como eu havia dito anteriormente os arquivos de textos explicativos de como utilizar os scripts, eu os preparei com a orientação para colocar os scripts em /home/nome_de_usuário/.nome_do_script, dessa forma, apenas o usuário em questão poderia utilizar estes scripts, semelhante ao que o sr. Brian faz. Mas a intenção é de permitir que todos os usuários de um mesmo computador possam utilizar os scripts não oficiais criados pela comunidade antiX. Eu terei que editar estes arquivos de textos explicativos e os ícones de atalho para o novo caminho.

    Como alguns destes scripts possui imagens novas que não existem no antiX, eu penso que seja melhor colocar em /opt, ao invés de colocar em /usr/local/bin.

    Sr. Brian, muito obrigado por compartilhar a informação de como o senhor utiliza os scripts não oficiais.

    Enquanto eu digitava, o ModdIt e o anticapitalista fizeram as suas considerações, obrigado.

    marcelocripe
    (Texto original em Português do Brasil)

    #54783
    Member
    skidooskidoo

    I just don’t know if storing in different folders generates some kind of rework for the development team.

    Your apparent intent is to produce “zipfiles”. That detail (expecting others to consume zipfiles) and your apparent insistence to adhere to that detail is what would “generate unnecessary rework”. For an single contributed script (or single contributed collection of scripts+resources), the extra chore of dealing with intermediary zipfiles may be, or might not be, feasible.

    antiX programs are delivered via, installed via, .deb files
    and the content to be delivered via the .deb files is maintained, is “collaborated”, via git project source code repositories. You seem to be asking collaborators and antiX developers to, instead, consume zipfiles which you intend to provide ~~ forcing someone else to extract from zipfile and add it to the appropriate git project source code repository. (just emphasizing/explaining here, not scolding)

    Click this link and notice that many of the existing scripts in use which might be described as “community scripts” are (already) provided by the “antix-goodies” .deb package
    https://gitlab.com/antiX-Linux/antix-goodies/-/tree/master/bin

    Click this link and notice that, via the installation manifest, a debfile can install various content to various (multiple) specified directories
    https://gitlab.com/antiX-Linux/antix-goodies/-/blob/master/debian/install
    When collaborating, and intending to have your content (scripts//icons//.desktop//.mo) installed via debfile, you really do not need to “worry about” the detail of what is the appropriate installed locations ~~ you can relegate that detail, that decision, to the person who is acting as the “package maintainer” for the debfile targeted by your content. Additionally (as an additional consideration), the person maintaining the gui & cli ControlCenter packages can add an entry (button, label) if we intend the new script to be accessible via ControlCenter.

    Placement to / opt… installed executables are accessible to all users …
    Does the same rule apply to scripts if they are placed in the “/usr/local/bin/” folder?

    As sysadmins, as package maintainers… we are responsible for making the rules. If the existing rules do not suit us (users on our systems), we modify them. The remark stating “/opt accessible to all users” just describes the convention(al) case. Any debfile can provide overriding instructions, for instance “install myProgram to /opt/myex AND set its permission so that it is executable only by user accounts which are are members of ‘advancedusers’ group”.

    A sysadmin (or a package maintainer) can specify, for each individual executable residing in /usr/local/bin/, a restrictive permission set. You can notice that, on an antiX system, /usr/local/sbin/ exists… but is empty. On another operating system, we might expect this (by convention) to be an installation destination for “executable only by root user, or via elevated permissions” programs. You can also notice (via ‘ls -al /usr/local/bin’ or browsing via file manager) that yes (answering your question “does the same ‘rule’, same as /opt, apply?) all the executables residing here are executable by all usergroups. Perhaps confusingly, many of the executables residing here do refuse to run if they are not launched with elevated permissions, but such restriction is a separate consideration.

    • This reply was modified 3 days, 15 hours ago by skidoo.

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #54810
    Forum Admin
    DaveDave

    Is sbin really for only programs requiring root/elevated permissions?
    My understanding was that sbin meant system binaries and bin was for other “normal” binaries. /usr/(s)bin directories where for binaries that operate in a multiuser environment (after /usr is known to be mounted; init 3?) and /usr/local/(s)bin for self (locally) made / custom programs. /opt for optional programs. Example libreoffice has a standard system version installed via the package manager but you may also need to use an newer (older?) version which would be kept in /opt.

    Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

    #54812
    Member
    skidooskidoo

    Dave, as a generalization, perhaps it’s safer to only say “/usr/local/sbin/ is generally empty”.
    I rechecked and found that the details are not well defined, neither within debian policy nor in the LSB.

    https://serverfault.com/questions/113675/what-is-the-difference-between-usr-local-bin-usr-local-sbin

    (from terminal emulator)
    echo $PATH
    /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin

    (from a sudo-permissioned terminal emulator)
    echo $PATH
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

Viewing 15 posts - 1 through 15 (of 17 total)
  • You must be logged in to reply to this topic.