Zip-Archive mode works on systems with zip/unzip. How do you get it to work on Wnidows?
EMACS uses an external program to do the compression/uncompression. All it needs is to know the right program to use.
Some extended discussion:
As I say, i've got no Windows box, but the LISP code is in arc-mode.el at about line 230:
(defcustom archive-zip-extract
(if (and (not (executable-find "unzip"))
(executable-find "pkunzip"))
'("pkunzip" "-e" "-o-")
'("unzip" "-qq" "-c"))
"*Program and its options to run in order to extract a zip file member.
Extraction should happen to standard output. Archive and member name will
be added."
:type '(list (string :tag "Program")
(repeat :tag "Options"
:inline t
(string :format "%v")))
:group 'archive-zip)
Observe the function executable-find. It searches in your EMACS exec-path, which includes some EMACS executable directories that aren't in your normal PATH variable. In my case, it's:
("/usr/bin"
"/bin"
"/usr/sbin"
"/sbin"
"/Applications/Emacs.app/Contents/MacOS/libexec"
"/Applications/Emacs.app/Contents/MacOS/bin"
"~/bin"
"/usr/local/bin"
"/usr/X11R6/bin")
which includes the two directories inside the EMACS package. Your Windows installation will include equivalent directories somewhere down in the guts of the EMACS setup. That's where to look for the executables if they're not in your regular path.
You can download pkunzip from this site, install it, and add the path to the installation with (add-to-list 'exec-path "c:/path/to/pkunzip")
How emacs handles compressed files can be a little confusing, but here is an attempt to summarise the situation. There are two main compression packages: arc-mode (e.g. zip-archive mode) and jka-compr mode (auto-compression-mode).
arc-mode: will display the table-of-contents (i.e. simple list of filenames contained within the archive) of multi-file archives (arc, lzh, zip, zoo) without requiring the relevant third-party tool to exist on your system. If you actually want to do any viewing/editing of the actual files contained within the archive using arc-mode you will definitely need the third-party tool to be installed on your system and in the appropriate location. E.g. for zip files it defaults to zip/unzip in the exec-path (which is the operating systems PATH environment). This can be customised using archive-zip-extract and archive-zip-expunge.
jka-compr (auto-compression-mode): will automatically compress/uncompress single file archives (gz, Z, bz2, tbz, etc) and requires the relevant third-party tool to exist on your system.
So to get zip-archive mode fully working on Windows you will just need to find a windows version of command-line zip/unzip and put them into a directory that is in your PATH (e.g. see unzip package at http://gnuwin32.sourceforge.net/).
you can use [chololatey]: https://chocolatey.org/ , the package management for windows , to install unzip.
choco install unzip
Related
I would like to release my program that wrote in ruby language, I need to pack ruby to appimage file and send it to my client ubuntu PC first.
so I create the folder "ruby-img", then copy my compiled ruby which in "/app/ruby" folder to "ruby-img/app/ruby" and then made a link as "ln -r -s app/ruby/bin/ruby usr/bin/." in "ruby-img" folder.
then I create the desktop file and put png file to "ruby-img", using appimagetool to create ruby-x86_64.AppImage. sadly it can not run, AFAIK that ruby.AppImage still using /app/ruby/lib folder to find some library of ruby but not in "ruby-img/app/ruby/lib" related folder.
so I tried re-compile ruby as --prefix=/tmp/ruby or --prefix=/usr/local/ruby, then copy them to "ruby-img/usr/local/ruby" or "ruby-img/tmp/ruby" then maka some link as above, and repack to AppImage but ruby.AppImage still not working...
any idea can help me ?
AppImages contain of a filesystem with all the content you provide plus a small executable stub that will mount the AppImage filesystem, then run the AppRun executable to be found inside.
With that knowledge it is utmost important that you provide an executable in the root directory along with the .desktop and icon files. I suggest you do not create AppRun yourself. Use the precompiled one from https://github.com/AppImage/AppImageKit/releases/tag/continuous (do not forget to rename it to exactly 'AppRun').
Now when this AppRun gets invoked, it will perform a few checks, cd into the /usr directory and try to start the executable specified in the .desktop file. Check it's source code and you can see that it also sets a few environment variables.
Therefore it is best you provide your entrypoint as /usr/bin/ruby.sh and register that in the desktop file. Remember if /usr/bin/ruby.sh gets called, the current work directory is /usr. So ruby.sh can set further environment variables such as LD_LIBRARY_PATH so that the libraries you configured for /usr/lib will actually be loaded.
With that I hope you have at least as much success as I had.
I'm learning to use GNU/Linux and I want to know how to install programs that cannot be installed with the package manager.
I downloaded the tarball with the Linux 64-bit Binaries (including one called "haxelib"), extracted it, changed directory in the terminal to their location (~/Downloads/things/haxe_20201231082044_5e33a78aa/), and used chmod to make them executable.
If I try a command such as haxelib list, then the terminal returns
haxelib: command not found
If I try ./haxelib list (the same command but with ./ at the start) instead, then the command works as expected.
Why can't I use it without the ./? Programs installed with the package manager can be used without the ./.
Edit: I should probably also ask: where should I put the files from the tarball? Should they all go together in the same place? I have a feeling that a folder named "things" in my Downloads folder is not the best place for them.
The header files are typically installed with Python. On Unix, these are located in the directories $prefix/include/pythonversion/ and $exec_prefix/include/pythonversion/, where $prefix and $exec_prefix are defined by the corresponding parameters to Python's configure script and version is sys.version. On Windows, the headers are installed in $prefix/include, where $prefix is the installation directory specified to the installer.
So I have this macro
Macro
the problem is on this piece of code
if test "$PYTHON_PLATFORM" != "win32"; then
py_versiondir="/python${PYTHON_VERSION}"
else
py_versiondir=
fi
MinGW (on windows) for example can have versioned header python folder so the script don't work.
How I can fix it?
Since you're writing for Autoconf, you should consider adding the AX_PYTHON macro from the Autoconf Archive to your package, and using it. (Be mindful of licensing requirements if you do this.)
Or if, for whatever reason, you don't want to use AX_PYTHON then at least have a look at it to see that it works by getting Python to tell it the answer. Here's the heart of it:
ax_python_header=`$ax_python_bin -c "from distutils.sysconfig import *; print(get_config_var('CONFINCLUDEPY'))"`
($ax_python_bin is previously set to the path to a Python executable.)
I'm creating a Linux tgz self-extracting installer using CPack and I'd like the installer to run a script or sequence of commands after all files have been installed. CPack documentation contains the following guidance:
CPACK_INSTALL_COMMANDS Extra commands to install components.
I set this variable in my CMakeLists.txt file and I see it set in the resulting CPackConfig.cmake file, but the commands I embed in this variable do not appear anywhere in the final .sh install script. What am I missing?
You're not missing anything, that's simply not how the CPACK_INSTALL_COMMANDS variable works.
On a typical project, CPack does a "make install" into a temporary location, in order to build the final installer based on the "make install" tree. The CPACK_INSTALL_COMMANDS variable is meant to be set for projects that would rather run some other command sequence, instead of the typical "make install" in order to produce the install tree.
So, CPack should be running your commands as it generates the package. It will not run your commands on the end user's machine at the end of him/her running the generated installation script...
There are per-generator ways of running installed executables and/or scripts at the end of the end user installation, but it will require some customization on your part. In this case, I'd recommend attempting to override the CPack.STGZ_Header.sh.in input file that is used when CPack generates the STGZ self-extracting script. Customize that file and add your calls to the bottom of it, above the line:
exit 0
To override the file, provide your own copy of it in your source tree, perhaps in a ${CMAKE_CURRENT_SOURCE_DIR}/CMake directory, and then in your CMakeLists.txt file, add:
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/CMake ${CMAKE_MODULE_PATH})
(Actually, as I'm writing this, I'm wondering if that's sufficient, or if the module path also needs to be set at the time that CPack runs... Try this, and let us know if your customization gets used by CPack or not. If not, I'll investigate a bit further and add some more advice here.)
I got a pkg file in which I can change the installation directory when launched using the UI, but the manpage of installer only mention the target drive to install to.
Is there an environement variable to set when calling the installer ?
About the target options, from installer help :
The -target <device> parameter is any one of the following:
(1) One of the domains returned by -dominfo.
(2) Device node entry. Any entry of the form of /dev/disk*.
ex: /dev/disk2
(3) The disk identifier. Any entry of the form of disk*. ex: disk1s9
(4) Volume mount point. Any entry of the form of /Volumes/Mountpoint.
ex: /Volumes/Untitled
(5) Volume UUID. ex: 376C4046-083E-334F-AF08-62FAFBC4E352
So target is a "hard drive", not the "root path" where the pkg should be installed.
Most package managers include options to relocate (that is, change the installation path of) a package, on RPM-based Linux systems rpm has the option -relocate, on OS X, command line tool installer has the option -target.
However, as you have noticed, you can't specify an arbitrary path as argument to -target, as you would do with rpm's -relocate
The arguments to -target are limited to (see man installer):
A volume mount point (/Volumes/HDD), device node (/dev/disk0s5) or volume UUID (376C4046-083E-334F-AF08-62FAFBC4E352).
Any of the values returned by -dominfo (like LocalSystem or CurrentUserHomeDirectory), for example.
You write:
I got a pkg file in which I can change the installation directory when
launched using the UI
If that's the case, that information can probably be queried with -dominfo like this:
installer -verbose -dominfo -pkg <path to your package>
and can be used when installing from the command line:
installer -pkg <path to your package> -target <dominfo as listed above>
(I have queried several pkg files and all return NoDomainsAvailable, so can't share any experience.)
Keep in mind that, though, you can't arbitrarily relocate a pkg file. The reason is that configuration files, binaries and libraries included in the package usually specify or depend on absolute paths.
The package builder must actively convert those into relative paths (using postinstallation scripts and techniques like #rpath). So, generally speaking, you can only relocate a package that has been built with relocation in mind.
Your question is quite unclear: If you run the installer from the GUI and there is only one drive offered to install to, you can not change it in an easy way (means: you have to make changes to the installer package to install in a different location than offered by default).
Since you are using the "cli"-Tag (command line interface), I think you are trying to run the installer not on the GUI, instead you are running it from the terminal. There you have more options: With the -target option, you can set the installpath for your installer.
Information from the man-pages on the -target-Option:
The target volume is specified with the -target parameter ( -tgt is
accepted as a synonym). It must already be mounted when the installer
command is invoked.
Additional informations on how to run an installer from the Terminal (cli), you will find on my blog.