Idk, never used screen. Should work as long as there’s no hotkey overlap.
I dislike screen, so yeah.
Oh, @oO.o you might find this tip/trick helpful:
Late to the party… when messing with React in VSCode, it’s defaulted to 2-space indentation.
Yep, that’s blasphemy and should be treated as such.
That’s also why react is shit.
Do you use | and - to split as well instead of % and " ?
n for horizontal split (like open a new pane and horizontal split is just the default). And I use
N for a new window.
Also didn’t realize for a long time that you can just click on the tabs in the status bar to switch windows if mouse is on.
Nah, I like % " a lot better.
I’m using C-\ for prefix which I like better than C-a which seems the most popular.
Same muscle memory as leader for vim.
Less of a problem, more a question but:
Sometimes when installing software or plugins for software there is no pre-built package available and so they need to be self-compiled, which is fine. Sometimes their instructions include installing the files into some system directory automatically. Question regarding that: Is there any way to track which files are being written in that process and where?
Example: I just found the DeaDBeeF MPRIS2 Plugin and I already installed it and it works (although I had to move it to
~/.local/lib/deadbeef because it wouldn’t work in the default location, but I wanted that anyway). This thing happens to print where it puts the files, but not every random code on the internet does that. Suppose the
make install doesn’t do that, how would I find which files were being written?
On RPM based systems, you can use
rpmbuild. On Debian systems RPM systems, you can use
Fedora. But does
rpmbuild work for random files being put somewhere?
Also I can’t seem to find it in dnf?
[[email protected] ~]$ rpmbuild bash: rpmbuild: command not found [[email protected] ~]$ dnf info rpmbuild Last metadata expiration check: 0:00:56 ago on Thu 20 Aug 2020 11:31:47 CEST. Error: No matching Packages to list [[email protected] ~]$ dnf search rpmbuild Last metadata expiration check: 0:01:07 ago on Thu 20 Aug 2020 11:31:47 CEST. =========================================== Name & Summary Matched: rpmbuild =========================================== drupal7-rpmbuild.noarch : Rpmbuild files for drupal7 ghc-rpmbuild-order.x86_64 : Haskell rpmbuild-order library ghc-rpmbuild-order-devel.x86_64 : Haskell rpmbuild-order library development files ghc-rpmbuild-order-doc.noarch : Haskell rpmbuild-order library documentation ghc-rpmbuild-order-prof.x86_64 : Haskell rpmbuild-order profiling library ================================================ Name Matched: rpmbuild ================================================ copr-rpmbuild.x86_64 : Run COPR build tasks drupal8-rpmbuild.noarch : RPM build files for drupal8 rpmbuild-order.x86_64 : Order RPM packages by dependencies ============================================== Summary Matched: rpmbuild =============================================== auto-buildrequires.x86_64 : Work out BuildRequires for rpmbuild automatically copr-builder.x86_64 : copr-rpmbuild with all weak dependencies perl-macros.noarch : Macros for rpmbuild rpmautospec-rpm-macros.noarch : Rpmautospec RPM macros for local rpmbuild
I have not use rpmbuild in a long time. I always default to checkinstall. It builds a standard RPM for you and you would then install that.
So if you wanted uninstall what you did with the tarbal and then run
make && checkinstall instead, you then use rpm, dnf, or yum to install the application.
I have not use rpmbuild since like 2003, so maybe it is no longer maintained. You could also use alien if your distro does not have checkinstall available. But that is also ancient.
Mh I haven’t really looked into how building an RPM works, but I always thought it needed a specfile to begin with?
What I mean is more if there is no package available at all, only the source code. The
make install puts the files whereever it thinks they need to be, but I’d like to know what was being put where.
Building an RPM would need to be set up beforehand, no?
checkinstall seems to be tracking what
make install does and writes, so that seems like the right thing. But it’s not available either
Yeah. when you have checkinstall installed, instead of doing the
make && make install step you do
make && checkinstall it then builds the rpm (or deb or tar.gz) for the target system and then gives you the option of installing that package or not.
Looks like checkinstall is a Debian creation, but you can build it for Fedora or what ever you are using.
Alien will do the same thing as rpmbuild. Otherwise, yes, if you want to build your own rpm the hard way, you will need to create a spec file and make sure you have your distro’s version of packager to kelp you convert that into a proper rpm, like fedora-packager
Yeah guessed that, but that would require a lot of coding for random things I just want to test or whatever, which is not the goal
I’ll probably look into checkinstall unless someone has another idea thanks
And to better answer your question. There is no easy way of doing this. That is why package managers were created. You can then do things like ask, what files does this package create, where does it put these files when installing, or even better, what package installed this file and what is the application that governs it.
Yeah I’m familiar with the concept of package managers, but unfortunately not every piece of software (especially smaller ones) provides packages for every distro
I thought maybe
strace should be able to, but I guess writing a file is not a syscall then? At least it doesn’t appear when doing
strace make install
You could use tee and redirect the output of tee to a file? But yeah. I find it interesting that you don’t have access to a native package builder without having to do things the old Red Hat way. But then Debian has more packages and any other distro, so maybe I have been spoiled over the decades.
** I used to use alien all of the time to convert Debian packages to rpms back in the day. debs tend to have more metadata than rpms so they seemed to have better integration into my Red Hat system than some peoples custom compiled rpms.
I mean I could build an RPM but I would need a specfile I guess, which is what I’m trying to avoid when I just wanna test something for 5 minutes and not fiddle around with it for 3 days