I think this should be closed.

I don't think it should be closed and I'm preparing an example that can be added to the main README.md.

from walk.

You can run any executable by typing its path, e.g. type ./walk after running make. If you want to just type the name, e.g. walk, you need to install the executable by copying it to a directory in your $PATH.

from walk.

Many thanks. It works.

from walk.

I think this should be closed.

from walk.

Hello again,

I tested these steps on Ubuntu 20.04 with bash for shell.

There's only one distinction in the installation steps, whether the user prefers a local (user-only) installation, or system-wide (requires root/sudo access).

Step 1: build from source

git clone https://github.com/google/walk.git
cd walk
make

Step 2A: Installation for non-root user

mkdir -p ~/local/{bin,share/man/man1}
cp -av -t ~/local/bin sor walk
cp -av -t ~/local/share/man/man1 sor.1 walk.1

cat << EOF > ~/.walkrc
export PATH="\${PATH}:\${HOME}/local/bin"
export MANPATH="\${MANPATH}:\${HOME}/local/share/man/man1"
EOF

cat << EOF >> ~/.bashrc
if [[ -f ~/.walkrc ]]; then
    . ~/.walkrc
fi
EOF

Step 2B: Installation as root (system-wide)

sudo mkdir -p /usr/local/{bin,share/man/man1}
sudo cp -av -t /usr/local/bin sor walk
sudo cp -av -t /usr/local/share/man/man1 sor.1 walk.1
sudo chown root.0 /usr/local/bin/{sor,walk}
sudo chmod 755 /usr/local/bin/{sor,walk}
sudo chown root.0 /usr/local/share/man/man1/{sor.1,walk.1}
sudo chmod a+r /usr/local/share/man/man1/{sor.1,walk.1}

You can test the installation(s) like this:

which sor
which walk
man sor
man walk

It should display the paths to the binaries and the man pages correctly.

IMHO, this actually belongs in the makefile, but it's literally better to have some shell commands documented than nothing.
Unfortunatelly, I don't know how to write good Makefiles.

Anyhow please someone test this and confirm the steps also work for you.

from walk.

There's only one distinction in the installation steps, whether the user prefers a local (user-only) installation, or system-wide (requires root/sudo access).

[…]

IMHO, this actually belongs in the makefile, but it's literally better to have some shell commands documented than nothing. Unfortunatelly, I don't know how to write good Makefiles.

Seems overkill to me, just drop an install: target with PREFIX into Makefile, with four cp commands.
IMO no shell runcontrol editing should be performed in the setup, either the file goes into a standard directory in PATH or the user has to know what they are doing.

Rather than this I'd focus on the fact that I have not been able to get a reply from either @bbarenblat or @cryslith since 2021-01-29, where I asked for an official release tag or Void wouldn't package it.

I don't know what other systems packaging policies are but I guess it wouldn't hurt having a proper release.
If anything ask your distro managers to package this, having this available in "mainstream" distributions (Debian, Ubuntu, Centos, WhateverOS) is likely to have a bigger impact on end-user adoption.

I like the utility very much and have switched my memory muscle to use it in place of find since I stumbled onto it, it bugs me not having the package on my everyday system official repo (I carry the package I built around).

from walk.

@anddam How is that possibly my problem? It's not my software.

from walk.

My bad, I just went over the "Contributors" side panel on the repo.

I'll reply in #3 .

from walk.

Hello! Original author here. I’m not sure how I missed this. I’m not opposed at all to adding a make install target; I’ll add one right now.

The primary development repository for this project has moved to https://git.benjamin.barenblat.name/walk (mirrored at https://github.com/bbarenblat/walk), so watch that space.

from walk.