DEV Community: dpm_bush

Choosing a WinSCP Alternative: Start With the Job, Not the App

dpm_bush — Thu, 15 Oct 2026 05:15:24 +0000

WinSCP already does a lot: SFTP, SCP, FTP/FTPS, WebDAV and S3, plus directory synchronization and Windows scripting. If you’re looking for an alternative, the useful question isn’t “Which app is best?” It’s “Which part of my workflow does WinSCP no longer fit?”

That distinction matters. A tool that works on macOS may not offer WinSCP’s automation, and an SSH terminal with a file browser may not replace a dedicated transfer client.

First, identify the task you need to replace

List what you actually use before comparing apps:

Moving files manually: Do you need a two-pane browser, transfer queue, or support for several protocols?
Connecting from another operating system: Are you moving to macOS or Linux, where WinSCP doesn’t offer a native desktop app?
Working with cloud storage: Do you need S3, Google Drive, OneDrive, or another provider?
Administering a server: Do you want a terminal and file browser together, or are you happy using separate tools?
Automating transfers: Do existing scripts, scheduled jobs, or .NET integrations depend on WinSCP?
Mounting remote files: Do you want remote storage to appear in Finder or File Explorer, rather than opening a transfer client?

These are different needs. A mount tool, a terminal emulator, and an SFTP client aren’t interchangeable just because each can access remote files.

It also helps to check the protocol requirement. SFTP runs over SSH; FTPS is FTP secured with TLS. They’re distinct protocols, so a client supporting one doesn’t necessarily support the other. If you’re weighing transfer options, this SFTP client comparison can help you narrow the category before picking an app.

Shortlist by operating system and workflow

If you want a free, cross-platform file-transfer client

FileZilla Client is a straightforward starting point for FTP, FTPS, and SFTP on Windows, macOS, and Linux. Its standard client is free. Some cloud integrations are part of FileZilla Pro, so check which edition supports the services you need.

It’s a practical choice when your core job is browsing local and remote files and transferring them. It isn’t a one-for-one substitute for WinSCP’s Windows scripting and .NET assembly.

If you need SFTP plus cloud storage

Cyberduck is available for Windows and macOS and supports SFTP alongside a range of cloud storage services. The base app is free and open source. It’s a file and storage browser, not an interactive SSH terminal, and it doesn’t have a native Linux desktop release.

If you’re on macOS

ForkLift offers a Mac-native, two-pane file-manager workflow with remote connections and cloud services. Transmit is another paid Mac option focused on transfers and synchronization. They’re not Linux or Windows replacements, and their licensing differs. Check current platform requirements and terms before buying.

If you want a Windows SSH terminal and graphical SFTP

Bitvise SSH Client combines SSH terminal and graphical SFTP workflows on Windows. It’s a reasonable option if you’ve been using WinSCP alongside a separate terminal client.

MobaXterm is a broader Windows toolbox that includes SSH, SFTP, and tools for other remote-access workflows such as X11. Its free Home edition has limits; check the current edition details if saved sessions, tunnels, or macros matter to you.

If automation is the priority

Don’t switch away from WinSCP just because a different client has a newer interface. WinSCP’s scripting interface and .NET assembly can be important parts of a deployment or backup process. A graphical alternative may not run those jobs, and another command-line tool won’t automatically understand existing WinSCP scripts.

For cross-platform transfer automation, rclone is worth evaluating. It supports SFTP and many cloud backends, but it’s a command-line tool rather than a two-pane file manager. Be especially careful with synchronization: rclone sync can delete files at the destination to make it match the source. Test paths and use a dry run before relying on a new job.

Also distinguish SCP from SFTP when migrating. WinSCP supports both, but many modern workflows use SFTP; this explanation of how SCP and SFTP differ is useful if an old script or server specifically requires SCP.

Migrate without breaking a working setup

Treat a client migration like a small infrastructure change—not just an app install.

Inventory your saved sites. Record hostnames, ports, usernames, protocols, key locations, proxy or jump-host settings, and default remote directories.
Find every automation dependency. Search for scheduled tasks, scripts, and applications that invoke WinSCP. A site you rarely open manually may still be used by a nightly job.
Recreate connections using supported import tools. Don’t assume a destination client can import WinSCP’s settings. An export file can also contain sensitive connection details, so protect it accordingly.
Verify the server’s identity. When the new client first connects, check the host-key fingerprint through a trusted channel. Don’t accept a changed or unfamiliar key just to get past a warning.
Test a harmless transfer. Confirm the remote directory, permissions, file contents, and transfer direction before editing production files or changing a sync job.
Keep a rollback path. Retain the old configuration and scripts until the replacement has passed the real tasks you depend on.

A practical decision rule

If you use Windows and mainly need reliable file transfers or mature WinSCP scripts, staying with WinSCP may be the simplest choice. If you need a native Mac or Linux client, start with a cross-platform transfer tool. If you want a Windows terminal alongside graphical SFTP, evaluate an SSH client that includes both. If repeatable automation is the job, test the replacement’s command-line behavior before migrating production tasks.

The best alternative is the one that covers the specific gap without quietly removing a feature you rely on. If WinSCP still handles your workflow, there’s no technical prize for replacing it.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Choosing a Termius Alternative: Match the Client to Your SSH Workflow

dpm_bush — Thu, 15 Oct 2026 04:31:04 +0000

Replacing an SSH client is easy to regret if you compare only terminal screenshots. The real question is which parts of your workflow you need to keep: mobile access, saved hosts, graphical file transfers, port forwarding, or tools for working on the server after you connect.

Termius already has a free Starter plan with SSH, SFTP, and port forwarding. Its paid plans add features such as a personal cloud vault and device synchronization. If those free features are all you use, switching may not solve a problem. If you rely on synced hosts or mobile access, a desktop-only alternative may be a downgrade even if it costs less.

Start with the job you need the client to do

Write down what you actually do in a typical session. For example:

Connect to a few servers from one Windows machine.
Open several terminal sessions and keep them organized.
Upload files through a graphical SFTP browser.
Forward a port to reach a service on a remote server.
Connect from a phone when away from your computer.
Share hosts or credentials with a team.

These needs point to different tools. “Supports SSH” is only a starting point: it does not tell you whether an app has graphical SFTP, a mobile app, team controls, or a convenient way to manage tunnels.

A useful distinction: SFTP support is not the same as a graphical SFTP file manager. OpenSSH provides command-line tools such as sftp; a client with a visual file browser is a better fit if you want to drag and drop files. Similarly, SSH port forwarding carries traffic through an SSH connection; it is not the same thing as an embedded remote-desktop client.

Match the alternative to your setup

You want a free desktop terminal

Tabby is a free, open-source terminal for Windows, macOS, and Linux. It offers SSH sessions, tabs, split panes, and customization through plugins. It is a reasonable choice if you want a configurable desktop workflow and do not need Termius-style synced hosts across desktop and mobile devices.

Tabby is based on Electron, and its maintainers do not describe it as lightweight. Choose it for its features and customization rather than assuming it will use fewer resources than another client.

You need SSH, graphical SFTP, and tunnels on Windows

Bitvise SSH Client is a free Windows option with SSH, a graphical SFTP interface, and port-forwarding features. The client is free for use in business environments too; its optional paid license concerns support and upgrade commitments. Bitvise SSH Server is separate software, so do not confuse the client’s terms with the server’s.

MobaXterm may fit if your Windows toolbox also needs RDP, VNC, or an X server for displaying remote Linux GUI applications. Its free Home edition has limits, so check the current edition terms before adopting it for a team or a larger set of sessions.

You mostly transfer files

WinSCP is designed around file transfers rather than being a full SSH terminal manager. It supports graphical transfers, scripting, and directory synchronization. If you mainly connect to upload releases or manage remote files, that focus may be an advantage. If you also need interactive terminal sessions, pair it with an SSH client or choose a tool that combines both workflows.

You want a minimal, command-line setup

Windows includes OpenSSH as an optional feature, and it is commonly available on Linux and macOS. You can connect directly from a terminal:

ssh user@server.example.com

For repeated connections, a host entry in your SSH config can save the hostname, user, port, and identity file. The SSH config file examples show how to organize those settings and connect with a short alias. OpenSSH is a good fit if you prefer ordinary text configuration over a graphical host manager; it does not provide a graphical SFTP browser by itself.

Treat migration as a security task

A saved host entry, a private key, an agent-loaded identity, and a team vault are different things. Do not assume one client can import all of them automatically. Record the host, username, port, key choice, jump-host settings, and any tunnels you depend on. Then test a few important connections in the new client before changing your existing setup.

Keep private keys private. Do not paste them into chat, tickets, or repositories to make migration easier. If you are moving or replacing keys, plan access and revocation deliberately; this overview of SSH key management covers the key lifecycle and the risks of leaving stale credentials in place.

Also verify server identity when connecting through a new client. If it warns that a host key has changed unexpectedly, investigate the change rather than accepting it just to finish setup. A successful password or key login does not, on its own, establish that you reached the intended server.

A practical decision checklist

Before settling on an alternative, test it with a non-critical host and answer these questions:

Can it use the authentication method and key you need?
Does it provide a graphical SFTP interface if you want one?
Can it reproduce your jump-host and port-forwarding workflow?
Does it run on every device you use, including your phone if necessary?
Are host sync and team sharing included, and do they meet your security requirements?
Can you get your configuration and credentials back if you lose access to the app or device?

If you only need occasional terminal access, OpenSSH or PuTTY may be enough. For free Windows SSH with graphical file transfer and tunneling, consider Bitvise. For a customizable cross-platform terminal, try Tabby. For mobile access and synchronized hosts, check that the replacement actually offers those capabilities before leaving Termius.

The best alternative is not the one with the longest feature list. It is the one that preserves the parts of your SSH workflow you rely on—and does not make you pay for, configure, or trust features you do not need.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Use the Linux tree Command to Understand a Project’s Structure

dpm_bush — Wed, 14 Oct 2026 00:35:07 +0000

ls is useful when you need to see what’s in one directory. But when you need to understand how a project’s folders fit together, a flat listing can hide the structure. The tree command displays files and directories as a branching outline.

Get a focused overview

Run tree with no arguments to start at your current directory, or pass a path to inspect a specific folder:

tree
tree ./project

A small project might look like this:

project
├── README.md
├── src
│   └── app.py
└── tests
    └── test_app.py

The branches make the parent-child relationships visible: src and tests are inside project, and each file appears beneath its parent directory.

A full recursive listing can quickly become unwieldy, especially in a repository with generated files or dependencies. Use -L to limit how many levels are shown:

tree -L 2 ./project

That gives you a useful first pass without expanding every nested folder. If the result is still noisy, start from a narrower path or combine the depth limit with filters below.

Install it if the command is missing

Check whether tree is available:

tree --version

If your shell reports that the command cannot be found, install the tree package using the package manager for your distribution:

# Ubuntu or Debian
sudo apt install tree

# Fedora
sudo dnf install tree

# Arch Linux
sudo pacman -S tree

# openSUSE
sudo zypper install tree

These commands install software system-wide and typically require administrator privileges. Afterward, verify the command with tree --version.

Shape the output around your task

A few options make the listing more useful without changing anything on disk:

# Show directories, not files
tree -d ./project

# Include hidden entries, such as .git
tree -a -L 2 ./project

# Skip bulky or irrelevant directories
tree -I 'node_modules|.git' ./project

# Show matching filenames while keeping their location in the tree
tree -P '*.conf' ./project

Use -d for a quick map of the folder layout. Add -a when hidden files matter; these are omitted by default. For a large repository, -I can leave out names you don’t want to inspect. -P selects names matching a pattern.

Quote wildcard patterns such as '*.conf'. The quotes stop your shell from expanding the wildcard before tree receives it. In the ignore example, patterns are separated with |.

You can also show extra file details:

tree -p -h -D ./project

This adds permissions, human-readable sizes, and modification dates to the listing.

Choose the right listing tool

Use tree when the relationships between nested folders matter. For a quick view of just the current directory, ls has options for hidden files, long-format details, and sorting. If you need to locate files by conditions rather than browse the hierarchy, find can search by name, type, size, and other criteria.

tree is also different from pstree: the former shows files and directories, while pstree shows running processes.

Save a listing to share or review later

Redirect the output to a text file:

tree -L 2 ./project > project-tree.txt

The > operator creates the file or replaces its existing contents. To append instead, use >>:

tree -L 2 ./project >> project-tree.txt

If you don’t want the report to appear in the listing, save it outside the directory you’re inspecting. Be careful with > if the destination file already contains something you need.

A few common surprises

The output is too long: specify the directory you care about and use -L to cap the depth. Try -d for a directory-only view or -I to skip noisy folders.

Some entries are missing: hidden names are excluded unless you use -a. Entries can also be inaccessible if your user cannot read the relevant directories. Check permissions on the path in question rather than automatically running the command with elevated privileges.

A filter doesn’t behave as expected: -P selects matching names; -I ignores matching names. Quote patterns so the shell passes them to tree unchanged. These filters affect the display, not the files themselves.

The command is installed but unavailable: you might be in a different system or container than expected, or its executable may not be on your shell’s PATH.

For most project inspections, start small: pick the directory, add a depth limit, then include hidden entries or filters only if the task calls for them. That produces a readable map without turning a quick check into a scroll through every file.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Using echo in Linux: Quoting, Redirection, and When to Use printf

dpm_bush — Wed, 14 Oct 2026 00:34:48 +0000

echo is handy for printing a quick message or checking a variable, but its behavior can be less predictable when you rely on options or backslash escapes. Knowing where the shell fits in—and when to switch to printf—helps avoid confusing output in scripts.

The shell processes text before echo sees it

A basic command prints its arguments to standard output, usually your terminal, followed by a newline:

echo Hello, Linux

Output:

Hello, Linux

The shell handles quoting and variable expansion before it runs echo. That means echo displays the value of a variable; it doesn't look up the variable itself.

echo "$HOME"
echo '$HOME'

The first command prints the value of HOME. Double quotes allow the shell to expand the variable while keeping its value together as one argument, including if it contains spaces. Single quotes prevent expansion, so the second command prints the literal text $HOME.

Double quotes also allow command substitution. The shell runs date, substitutes its output, and passes the resulting text to echo:

echo "Today is $(date)"

For more on making shell variables available to commands launched from the shell, see this guide to exporting environment variables in Linux.

Redirect output to a file

The shell—not echo—handles redirection. Use > to create a file or replace its contents, and >> to append to it:

echo "First line" > notes.txt
echo "Another line" >> notes.txt

Be careful with >: if notes.txt already exists, its contents are overwritten. The second command adds a line at the end instead. If you're choosing between echo and other ways to create a file in Linux, keep that overwrite behavior in mind.

What do `-n` and `-e` do?

Two options you may see are -n and -e:

-n suppresses the final newline in common implementations.
-e interprets selected backslash escapes in implementations that support it. For example, \n represents a newline and \t a tab.

In Bash, this prints two lines:

echo -e "one\ntwo"

However, echo can be a shell builtin or an external program, and implementations don't handle these options and escapes consistently. A command that works in one shell may behave differently in another. Avoid depending on -e for scripts that need predictable output.

You can inspect how your current shell resolves echo with this Bash command:

type -a echo

It can show whether echo is a builtin and whether an executable with the same name is also available. The behavior you get depends on which implementation is used.

Use printf when the output needs to be predictable

For short messages, echo is usually enough. Prefer printf when you need formatted output, need precise control over newlines, or want predictable handling of backslashes across shells.

printf 'one\ntwo\n'

For variables, use format placeholders such as %s and pass the values as separate, quoted arguments:

printf 'User: %s\nHome: %s\n' "$USER" "$HOME"

Here, \n in the format string creates a newline, and each %s is replaced by the corresponding value. Quoting the variable arguments keeps their contents as data rather than letting spaces split them into multiple arguments.

This distinction matters when text might begin with a hyphen. With echo, option-like text can be ambiguous because some implementations interpret options. printf makes the format explicit:

printf '%s\n' '-starting with a hyphen'

A quick rule of thumb

Use echo for a simple message when its default trailing newline is what you want. Use printf for formatted output or scripts where exact behavior matters. And remember that variable expansion, quoting, and redirection are handled by the shell before the command runs.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Linux `export`: How Shell Variables Reach Other Commands

dpm_bush — Wed, 14 Oct 2026 00:34:28 +0000

A variable you set in a terminal is not automatically available to every command you run. In Bash and other POSIX-compatible shells, export marks a variable so that commands launched afterward receive it in their environment.

That distinction matters when a script behaves differently from your interactive shell, or when you set a value and expect a separate program to see it.

Shell variable vs. environment variable

A shell can store a variable for its own use without passing it to child processes:

APP_MODE=development

Check it in the current shell:

printf '%s\n' "$APP_MODE"

But a new shell launched from that session does not inherit the value unless it was exported:

sh -c 'printf "%s\n" "${APP_MODE-unset}"'

This prints unset. The variable exists in the parent shell, but it is not part of the environment that the parent passes to the child.

Export it when you assign it:

export APP_MODE=development
sh -c 'printf "%s\n" "$APP_MODE"'

Now the child prints development.

You can also export a variable after assigning it:

APP_MODE=development
export APP_MODE

The assignment sets the value; export APP_MODE marks it for inheritance by subsequently launched child processes.

Environment variables flow downward

Exporting is about process inheritance. A child process receives the exported environment when it starts. If that child changes a variable, the change does not flow back into the parent shell. And exporting a value now does not update processes that were already running.

For a one-off command, you can set a variable just for that command without changing the parent shell:

APP_MODE=development sh -c 'printf "%s\n" "$APP_MODE"'

This is useful for testing a program under a particular setting. By contrast, export APP_MODE=development makes the variable available to later child commands launched from the current shell, too.

Common uses: `PATH` and application settings

A common reason to export a variable is to add a directory to PATH so commands launched from the shell can find programs there:

export PATH="$HOME/bin:$PATH"

This prepends $HOME/bin while preserving the existing PATH. Only add directories you trust and can use. Running the command repeatedly in the same shell adds the directory repeatedly, so take care before putting it in a startup file that may be read more than once.

Applications may also read environment variables for configuration. For example, if your network provides an HTTP proxy, you might set:

export HTTP_PROXY="http://proxy.example:8080"

That address is a placeholder; use the endpoint supplied for your environment. Applications vary in which proxy variable names they support, so check the application’s documentation. Avoid putting credentials in commands if they could be saved in your shell history.

Check, remove, or stop exporting a variable

In Bash and many POSIX shells, export -p lists variables marked for export:

export -p

Review the output before sharing it: environment variables can contain sensitive values. To print just one value, use:

printf '%s\n' "$APP_MODE"

An empty result does not tell you whether the variable is unset or set to an empty string. To distinguish those cases:

if [ "${APP_MODE+x}" ]; then
  printf 'APP_MODE is set\n'
else
  printf 'APP_MODE is not set\n'
fi

To remove a variable entirely from the current shell, use unset:

unset APP_MODE

In shells that support it, export -n APP_MODE removes the export attribute but retains the shell variable’s value. Future child processes will no longer inherit it.

Make a setting available in future shells

export changes the current shell environment; it does not make a setting permanent or system-wide. It also does not affect unrelated terminal windows. To have a variable set in future sessions, put an appropriate assignment in a startup file that the shell actually reads. Which file is right depends on the shell and whether it starts as a login or interactive shell.

After changing a startup file, open a new matching shell or source the file to apply the change to your current shell. Then check the value with printf. Be especially careful with startup-file changes to PATH: a typo can affect commands in every shell that reads that file.

If a script uses shell syntax, its interpreter matters: the shebang determines which shell runs it. See how to run a shell script in Linux for the distinction between invoking a script with a shell and running it directly. For Windows setups, choosing Bash or WSL can help clarify which shell is interpreting your commands.

When `export` is not recognized

export is a shell builtin in Bash and POSIX-compatible shells such as sh and dash; it is not a separate Linux package to install. If you see export: command not found, check that you entered the command at a shell prompt and that the expected shell is interpreting it. In Bash, type export identifies it as a builtin.

The practical rule is simple: assign a variable for use in the current shell; export it when future child processes need it. That small distinction explains many cases where a value appears in your terminal but not in the program you launch.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Use Linux `watch` for Live Command Snapshots

dpm_bush — Wed, 14 Oct 2026 00:34:06 +0000

Need to check whether disk space is changing, or see which process is using CPU without rerunning a command by hand? Linux watch repeatedly runs a command and refreshes its output in the terminal.

watch -n 5 df -h

This runs df -h every five seconds. By default, watch refreshes every two seconds. Press Ctrl+C to stop it and return to your shell.

Think snapshots, not streams

watch starts a command again at each interval; it does not leave one command running and display its ongoing output. That makes it useful for checking changing system state, but not for reading new lines as they are appended to a log.

For example, use watch for a refreshed process listing or filesystem summary. For a growing log file, use tail -f or tail -F instead. The right tool depends on whether you want repeated snapshots or a stream of new output.

Practical checks

Refresh memory usage every five seconds:

watch -n 5 free -h

Refresh uptime and load averages:

watch -n 5 uptime

Show a short process snapshot, sorted by CPU use:

watch -n 2 'ps -eo pid,comm,%cpu --sort=-%cpu | head'

The quotes around the last command matter: they pass the whole pipeline to watch, so it reruns both ps and head. Without them, your current shell may interpret the pipe outside watch.

These examples redraw the terminal; they do not save a history of earlier results. If you need interactive process inspection, top is usually a better fit because it lets you navigate and sort a continuously updated view.

Make changes easier to spot

The -d option highlights differences between successive outputs:

watch -d -n 2 free -h

To hide the header that shows the command, interval, and time, use -t:

watch -t -n 5 df -h

Some implementations support -c to interpret color sequences from the command output:

watch -c -n 2 'ls --color=always'

Color depends on both watch and the command producing it. If you see garbled characters, remove color-forcing options or try without -c. Options can vary by implementation and version, so check watch --help if an option is rejected.

Quoting and shell behavior

Pipelines and shell operators need to reach watch as part of the command it repeats. Put a pipeline in quotes, as in the process example above.

Also, do not assume that aliases or shell functions from your interactive session are available to the command watch runs. Prefer the executable name and its full options. If a command depends on a particular shell's syntax, invoke that shell explicitly and test the command by itself first.

When `watch` is the wrong tool

Use watch when you want to rerun a command and see its latest output. Choose something else when the task differs:

Follow appended log lines: use tail -f or tail -F.
Follow systemd journal messages: use journalctl -f.
Inspect processes interactively: use top.
Run a task on a schedule: use a scheduler rather than treating watch as a background monitoring service.

watch is an interactive terminal utility. It redraws the available screen, so long output may be truncated or difficult to read. Narrow the command's output or enlarge the terminal if needed. For more options when inspecting processes, see this guide to listing Linux processes with ps, top, and pgrep.

A quick troubleshooting checklist

If you get watch: command not found, check whether it is available:

command -v watch

If it is missing, install the package that provides it using your distribution's package manager; both the package name and install command depend on the distribution.

If the repeated command behaves unexpectedly, run it once without watch first. That makes command errors easier to see. Then check that pipelines are quoted and that the command does not rely on an interactive alias or function.

For an unrecognized option, consult watch --help on that system. And when all you need is one current result, run the command directly—there is no benefit to refreshing a snapshot you only need once.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Getting Started with tmux on macOS

dpm_bush — Wed, 14 Oct 2026 00:33:42 +0000

A terminal window closes, an SSH connection drops, or you need more than one shell in the same workspace. tmux helps by keeping terminal sessions organized—and, when it runs on a server, alive after your SSH client disconnects.

On a Mac, the setup is straightforward. The important distinction is where tmux runs: a local tmux session belongs to your Mac, while a tmux session started after SSHing into a server belongs to that server.

Install tmux

If you use Homebrew, install and verify tmux from Terminal or iTerm2:

brew install tmux
tmux -V

If you use MacPorts instead, install it with:

sudo port install tmux

Use one package manager for the installation rather than installing duplicate copies through both. You do not need to run tmux itself with sudo.

To see which executable your shell will use, run:

command -v tmux

That is useful if you have more than one installation on your Mac. Your shell runs the first matching executable in its PATH.

Start a session and come back to it

Create a named session so it is easy to find later:

tmux new-session -s work

You are now working inside tmux. Run commands as usual. To leave the session running and return to the regular terminal, press the default prefix Ctrl+b, release it, then press d.

These are sequential keystrokes—not a three-key chord. To reconnect, list sessions and attach to the one you want:

tmux list-sessions
tmux attach-session -t work

If there is only one session, tmux attach is also enough.

A local session stays available while your Mac is running, but it does not survive a Mac reboot. A session running on a remote server can remain available after your SSH connection drops, as long as the server and the session keep running. If you’re setting up that remote connection for the first time, this Mac-to-Linux SSH walkthrough covers the connection side.

The few keys worth learning first

Most tmux actions use the prefix Ctrl+b: press and release it, then press the action key.

Action	Keys
Detach and leave the session running	`Ctrl+b`, then `d`
Create a window	`Ctrl+b`, then `c`
Next or previous window	`Ctrl+b`, then `n` or `p`
Split a window side by side	`Ctrl+b`, then `%`
Split a window into stacked panes	`Ctrl+b`, then `"`
Move between panes	`Ctrl+b`, then an arrow key
Close the active pane	`Ctrl+b`, then `x`

A window is a workspace inside a session. A pane divides a window into multiple terminals. Closing a pane ends the shell running in it, so check which pane is active before confirming the prompt. You can also type exit in a pane when you are finished with its shell.

Copying text to the Mac clipboard

On macOS, tmux’s copy buffer and the system clipboard are separate. Copying a selection in tmux does not necessarily make it available to paste into another Mac app.

To select text in the default copy mode, press Ctrl+b, then [; move with the arrow keys, press Space to start selecting, and press Enter to copy into tmux’s buffer. To send that buffer to the Mac clipboard, run:

tmux show-buffer | pbcopy

pbcopy writes standard input to the macOS clipboard. You can then paste into another app normally.

There’s a location detail to watch for: if tmux is running on a remote server, a command inside that session runs on the server. pbcopy is a macOS utility, so running it remotely does not directly write to your Mac’s clipboard. The tmux buffer and the Mac clipboard are on different machines unless you set up a clipboard-forwarding method.

Troubleshooting a couple of common snags

tmux: command not found

Check whether Homebrew lists tmux and whether your shell can locate it:

brew list tmux
command -v tmux

If it is installed but command -v prints nothing, open a new terminal window and check again. If the problem remains, check your Homebrew shell setup and PATH rather than guessing where the executable lives.

The wrong tmux version starts

Run command -v tmux to see which executable is selected. This can reveal an older copy earlier in your PATH, or different installations managed by Homebrew and MacPorts.

SSH agent access behaves differently in an existing session

Long-running tmux sessions can retain environment variables from when they started. If SSH key access is the issue, first identify which machine and shell are running the command; SSH_AUTH_SOCK and agent sockets are a useful next step for understanding how an SSH agent is reached.

A practical way to think about it

Use local tmux when you want multiple terminal workspaces on your Mac. Use tmux on a remote machine when you want the server-side session to keep running through a dropped SSH connection. In either case, name sessions, detach instead of closing them, and reconnect with tmux attach-session -t name.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

pwd in Linux: Know Which Directory Your Shell Is In

dpm_bush — Wed, 14 Oct 2026 00:33:18 +0000

A command can behave differently depending on the directory your shell is in. Before you edit a file, run a script, or use a relative path, check your location with pwd.

What `pwd` tells you

pwd means “print working directory.” Run it without arguments:

pwd

You might see:

/home/alex/projects

That is the current working directory for this shell session. It is usually shown as an absolute path, starting at the filesystem root (/). A relative path such as src/app.js is interpreted from this location.

Your current directory is not necessarily your home directory. You can navigate elsewhere and return to your home directory later. To change locations, use cd and its directory-navigation shortcuts; pwd only reports where you are.

Each terminal or shell session tracks its own location. If one terminal is in /home/alex/projects and another is in /tmp, their pwd output will differ.

Use it before working with relative paths

Suppose you expect a configuration file to be in your project, but you are not sure where the terminal started. Check first:

pwd

Then inspect the current directory's contents:

ls

These commands answer different questions: pwd shows your location, while ls shows what is there. If you need to inspect hidden files or change how entries are displayed, see these practical ls examples.

This check is especially useful before commands that use relative paths. For example, ./script.sh refers to a script in the current directory—not necessarily the directory where the script is stored. If a command reports “No such file or directory,” an unexpected working directory is one possible cause.

Logical and physical paths

A directory may be reachable through a symbolic link. In that case, there can be two useful ways to describe your location:

The logical path preserves the path you used, including a symbolic link.
The physical path resolves symbolic links to the underlying directory.

On shells and implementations that support these options, request the logical or physical path explicitly:

pwd -L
pwd -P

For example, if /var/www points to /srv/site, the logical path may be /var/www, while the physical path may be /srv/site. The actual output depends on your filesystem and shell.

Plain pwd commonly reports a logical path in popular shells, but defaults can vary between shell built-ins and standalone utilities. If the distinction matters—for example, when diagnosing a path issue—use -L or -P and check the behavior of the shell you are running.

`pwd` on Windows depends on the shell

The command name does not mean exactly the same thing in every Windows environment:

In PowerShell, pwd is an alias for Get-Location.
In Command Prompt, use cd or echo %CD% to display the current directory.
In WSL or Git Bash, you are using a Unix-like shell where pwd is available.

So if pwd works in one Windows terminal but not another, check which shell that terminal is running.

A useful habit

When a command seems to be looking in the wrong place, verify the shell's current directory before changing files or retrying with different paths:

pwd
ls

The first command tells you where relative paths start; the second helps confirm what is in that location. That small check can prevent mistakes caused by assuming the terminal is somewhere it isn't.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Renaming Files in Linux: Safe mv Patterns and Batch Previews

dpm_bush — Wed, 14 Oct 2026 00:32:59 +0000

Renaming a file in Linux usually means moving it to a new path with mv. That works for a simple name change, but it also means the original path disappears—and an existing destination file may be replaced unless you take care.

Rename one file

Use the current name first and the new name second:

mv report-draft.txt report-final.txt

Because both paths are in the current directory, this renames the file in place. mv does not leave a second copy behind.

If you’re unsure where your terminal is, check with pwd, then list the current directory with ls. The ls command’s options can help you inspect names and file details before making a change.

Filenames with spaces or leading hyphens

Quote names containing spaces so the shell passes each filename as one argument:

mv 'quarterly report.txt' 'quarterly report final.txt'

Without quotes, the shell splits a name at its spaces, and mv receives extra arguments.

A filename that starts with - can be mistaken for an option. Prefix it with ./ to make it clear that it’s a path:

mv ./-draft.txt final.txt

On GNU/Linux, you can also use -- to mark the end of options:

mv -- -draft.txt final.txt

The ./ form is a straightforward way to avoid the ambiguity.

Avoid an accidental replacement

If the destination name already exists, common Linux mv implementations may replace it without prompting. Use -i to ask for confirmation before an overwrite:

mv -i old-name.txt new-name.txt

Review the prompt before answering. If you decline, the existing destination remains and the source is not moved over it.

You can check whether a destination currently exists with:

ls -l -- new-name.txt

Treat this as a quick inspection, not a guarantee: another process could create the destination after the check. If replacing a file would be especially harmful, check your system’s mv manual for the stronger protections available in that implementation.

Move and rename in one step

A destination path can include both a different directory and a new filename:

mv ./report-draft.txt ~/Documents/report-final.txt

This moves the file into ~/Documents and gives it the name report-final.txt. If you want to keep the original name, use the destination directory alone:

mv report-draft.txt ~/Documents/

In either case, mv relocates the original; it does not create a copy. If you need the old file to remain where it is, use cp instead. This guide to copying files with cp covers creating a copy under a different name.

Preview a batch rename before changing anything

For a repeatable batch operation, a Bash loop can show the proposed names before it renames files. This example previews adding archived- to .txt files in the current directory:

for file in ./*.txt; do
  [ -e "$file" ] || continue
  printf '%s -> %s\n' "$file" "./archived-${file#./}"
done

Review the output. If the paths look right, the same loop can perform the rename with GNU/Linux mv -n, which skips existing destinations:

for file in ./*.txt; do
  [ -e "$file" ] || continue
  mv -n -- "$file" "./archived-${file#./}"
done

These examples assume Bash and GNU coreutils. Try batch commands in a small test directory first, especially if files could produce conflicting destination names. The -n option and exact mv behavior can vary across implementations.

There is also a separate utility called rename, but multiple incompatible programs use that name. Its syntax depends on which implementation is installed, so check the local manual before using an example from another system.

One last distinction

Changing a filename extension changes only the name. Renaming report.txt to report.csv does not convert the file’s contents into CSV. Use mv when you intend to change a path or name; use a conversion tool when you need to change the file format.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Unix vs. Linux: What the Names Actually Mean

dpm_bush — Wed, 14 Oct 2026 00:32:37 +0000

A shell command that works on Linux may also work on macOS or a commercial Unix system—but similar command-line interfaces don’t mean the operating systems are identical. The distinction matters when choosing a platform, writing portable software, or figuring out what someone means by “Unix.”

The quick version: Linux is a kernel commonly used as part of a complete operating system. Unix describes a historical family of systems, and UNIX certification is a specific designation. Linux systems are often called Unix-like because they share conventions and design ideas, not because Linux is the original Unix.

First, separate the terms

These labels describe different things:

Linux kernel: The core software that manages hardware and provides services to applications.
Linux distribution: A usable operating-system environment built around the Linux kernel, together with tools, libraries, applications, and a package-management approach. Ubuntu, Debian, and Fedora are distributions.
Unix: A name associated with the operating-system lineage that began at Bell Labs and later developed into multiple systems.
Unix-like: A descriptive term for systems that share Unix traditions, interfaces, or conventions. It isn’t a certification.
UNIX-certified: A status granted to specific products and versions that meet the relevant Single UNIX Specification requirements and are permitted to use the UNIX trademark.

People often say “Linux” when they mean a full distribution rather than the kernel alone. That shorthand is common, but it can make comparisons confusing: are we comparing a kernel with an operating system, or a Linux distribution with a particular Unix product?

Linux began as an independent kernel project in 1991. It was influenced by Unix ideas, but it wasn’t released as a version of the original Unix source code. Many complete Linux systems are therefore Unix-like without being UNIX-certified.

Similar conventions don’t guarantee identical behavior

Unix systems and Linux distributions commonly share familiar concepts: users, processes, hierarchical filesystems, permissions, shells, and command-line utilities. If you know your way around one Unix-style shell, many everyday tasks will feel recognizable on another.

But resemblance isn’t a compatibility guarantee. A command can exist on both systems and still have different options, defaults, or implementations. Applications may also depend on system-specific APIs, libraries, or hardware support. POSIX standards define common interfaces that can help with portability, but meeting or targeting POSIX isn’t the same as UNIX certification—and doesn’t make every program portable without testing.

For example, a script using broadly supported shell syntax may transfer easily, while one relying on a utility option found only in a particular implementation may need changes. Check the target system’s manual and test on the platforms you intend to support rather than assuming matching command names behave exactly alike.

When working on a Linux host, it’s also useful to know which distribution you’re actually using; these commands for identifying a Linux distribution and kernel help distinguish those two details.

Licensing and development aren’t one-size-fits-all

There isn’t one license shared by every operating system called Unix. Licensing and source availability depend on the particular system and its components.

The Linux kernel is licensed under GPL version 2, but a Linux distribution brings together many projects, each with its own license. Distributions also differ in their policies and included components. Don’t infer a system’s redistribution terms, support model, or source availability just from the words “Unix” or “Linux”; check the specific product and version.

Development models differ too. Linux is developed collaboratively, with distributions integrating the kernel and other software into a complete system. Unix systems have their own histories, implementations, vendors, and release models. “Unix” doesn’t refer to one identical codebase or one uniform set of operating-system details.

Choosing a platform: start with the requirement

There’s no universal winner. The useful question is what your software, hardware, support contract, and team need.

Learning server administration or shell basics? A widely used Linux distribution is a practical place to start. Expect core ideas to transfer, but verify system-specific commands and behavior elsewhere.
Building software for multiple operating systems? Prefer documented, portable interfaces where possible, avoid unnecessary assumptions about utility options, and test on every supported target. POSIX can help, but it doesn’t replace testing.
Working in an organization with an established platform? Use the system required by the application vendor, operations team, or support agreement. A particular commercial Unix product or Linux distribution may be a hard requirement.
Choosing between Linux distributions? Compare release lifecycle, software availability, support, hardware requirements, and administration practices. For one common decision, this Fedora and Ubuntu comparison covers differences between two Linux distributions—not between Linux and Unix as a whole.

The takeaway

Linux and Unix share enough history and conventions that their command lines can feel familiar. But Linux is a kernel, Unix is a historical system family, and UNIX-certified is a product-specific status. “Unix-like” describes resemblance; it doesn’t certify a system or promise that every command and application will work unchanged.

When compatibility or support matters, identify the exact operating system and version, check the interfaces your software depends on, and test on the target platform.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

SSH Keys Explained: Public Keys, Private Keys, and Host Keys

dpm_bush — Tue, 13 Oct 2026 04:51:07 +0000

SSH keys can be confusing because “my SSH key” might mean a credential you use to log in—or a key the server uses to prove its identity. Those keys have different owners and jobs. Mixing them up can lead to authentication failures or, worse, trusting the wrong server.

The two halves of a login key

For user authentication, an SSH key is a public/private pair:

The private key stays under your control. Your SSH client uses it to prove that you possess the credential.
The public key is shared with a server or service that should allow your access.

On a typical OpenSSH setup, a private key might be named ~/.ssh/id_ed25519, with its matching public key at ~/.ssh/id_ed25519.pub. These names and locations are common defaults, not requirements; keys can use other filenames or credential stores.

The .pub suffix is a useful clue, but check the file’s contents and context rather than relying on a name alone. Public keys are intended to be distributed. Private keys are secrets: don’t paste them into websites, send them to a server, or commit them to a repository.

If you need to create a pair, follow a practical SSH key generation guide and keep the private and public files straight.

What happens during key authentication?

The server has to authorize your public key for the account you’re trying to access. In a common OpenSSH setup, that public key is listed in the account’s ~/.ssh/authorized_keys file on the server.

When you connect, your client offers a public key. If the server recognizes it as authorized, the client proves possession of the matching private key by creating a cryptographic signature. The server checks that proof with the public key. The private key itself is not sent over the network.

A successful key match is only one part of login. The username must be right, the key must be authorized for that account, and server policy must allow the authentication method. That’s why having a key on your laptop does not automatically grant access to every server.

Host keys answer a different question

A user key answers: “Is this client authorized to log in?” A host key answers: “Is this the server I meant to reach?”

The SSH server keeps its host private key. Your client checks the corresponding public host key and commonly remembers it in known_hosts. This verification helps detect when a server’s identity differs from what your client previously trusted.

A host-key warning is not the same as a rejected user key. A server rebuild or other legitimate change can produce a new host key, but an unexpected change can also mean you are connecting to a different machine. Verify the new fingerprint through a trusted channel before accepting it. Don’t disable host-key checking just to make the warning go away. If you encounter the specific “REMOTE HOST IDENTIFICATION HAS CHANGED” message, use this safe host-key warning workflow.

A passphrase protects the local key file

A passphrase can encrypt a private-key file at rest. When you use that key, you may need to unlock it directly or through an SSH agent or another credential tool.

It is not your remote account password, and public-key authentication does not send it to the server. The passphrase protects the local key file; it doesn’t change which keys the server authorizes. Protect the device and private-key file too. If someone can use an already-unlocked key, the passphrase may not stop them.

Key-based login also doesn’t necessarily mean there are no passwords involved: the server might still allow account-password authentication, and the private key may require a passphrase.

Quick checks when login fails

Start by identifying which part of the exchange is failing:

Check the account and destination. A valid key won’t help if you’re connecting as the wrong user or to the wrong host.
Check which key your client is using. You might have more than one key, or a key stored under a non-default filename.
Check server authorization. The public key must be authorized for the account you’re logging into; having it on a different account is not enough.
Keep warning types separate. A rejected user key concerns login authorization. A changed host key concerns the identity of the server.

The core distinction is simple: keep the user’s private key private, install or register its public counterpart where access is needed, and treat the server’s host key as a separate identity check. Knowing which key is involved makes SSH errors much easier to reason about.

If a private key is exposed, assume it may be compromised. Remove or revoke its public key wherever it is authorized, then create a replacement pair and grant access only where needed. Adding a passphrase after exposure does not undo the exposure.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

A Practical Guide to `tr`: Character-Level Text Processing in Linux

dpm_bush — Tue, 13 Oct 2026 02:04:43 +0000

tr is a small command-line tool for changing text one character at a time. It can translate characters, delete them, or collapse repeated characters—but it does not replace words or edit files in place.

That makes it useful in pipelines: pass text to standard input, transform it, and send the result to the terminal or another command.

Start with a translation

The basic form is:

tr [OPTION]... SET1 [SET2]

To map characters in SET1 to the corresponding characters in SET2, provide both sets. For example, convert lowercase letters to uppercase:

printf 'hello, linux\n' | tr '[:lower:]' '[:upper:]'

Output:

HELLO, LINUX

The POSIX character classes [:lower:] and [:upper:] express the intent more clearly than a range such as a-z. Quote sets so the shell passes them to tr as intended.

Translation is positional and character-by-character. This example maps a to 1, b to 2, and c to 3:

printf 'cab\n' | tr 'abc' '123'

The result is 312. For replacing longer strings or matching patterns, use a tool designed for that job; tr only works on individual characters.

Read from a file without changing it

tr does not accept a filename as an input operand. Use shell input redirection to feed a file into it:

tr '[:upper:]' '[:lower:]' < input.txt

This prints the transformed contents; input.txt stays unchanged. To save the result, redirect to a different file:

tr '[:upper:]' '[:lower:]' < input.txt > output.txt

Do not redirect output to the same file you are reading. The shell can truncate the destination before tr gets a chance to read it. If you need a refresher on inspecting file contents or combining files, see this guide to the Linux cat command.

Delete or keep selected characters

Use -d to delete every character that belongs to a set. This removes digits but leaves punctuation and spaces in place:

printf 'order 58: item 204\n' | tr -d '[:digit:]'

Output:

order : item

To do the opposite—keep digits and remove everything else—combine -d with -c, which complements the set:

printf 'order 58: item 204\n' | tr -cd '[:digit:]\n'

Output:

The newline is included in the set so the output retains a line ending. Here, [:digit:] matches individual digit characters, not a whole number as a unit.

Squeeze repeated characters

The -s option reduces each run of repeated characters in a set to one character. To collapse multiple spaces:

printf 'too    many spaces\n' | tr -s ' '

Output:

too many spaces

You can also translate tabs and spaces to a single space, then squeeze the result:

printf 'red\t\tblue\n' | tr -s '[:blank:]' ' '

[:blank:] matches horizontal blanks such as spaces and tabs. With translation enabled, -s squeezes repeated characters from the translated set (SET2). The newline is not a blank, so it remains intact.

A quick way to choose an operation

Goal	Pattern	Effect
Translate	`tr 'abc' '123'`	Map characters by position
Delete	`tr -d '[:digit:]'`	Remove characters in the set
Keep only a set	`tr -cd '[:digit:]\n'`	Delete characters outside the set
Squeeze	`tr -s ' '`	Collapse repeated spaces

These operations compose naturally with other filters. For example, you might normalize or remove characters before searching; the Linux grep guide covers the search step and common pattern-matching options.

Portability and text encoding notes

Common character classes include [:digit:], [:lower:], [:upper:], and [:blank:]. Quoted ranges such as 'a-z' are also common, but range ordering can depend on locale. Prefer character classes for case conversion when they express what you mean.

Behavior around locales, complements, and multibyte characters can differ between implementations. GNU tr provides -C to complement characters rather than bytes; do not assume that option is available everywhere. If byte-versus-character behavior matters, check the local tr manual page.

For predictable ASCII-oriented processing, you can run a command under the C locale:

LC_ALL=C tr '[:lower:]' '[:upper:]'

That changes how the utility interprets input, so use it when ASCII-oriented behavior is appropriate—not as a universal fix for arbitrary text.

One final distinction is worth remembering: tr writes transformed output to standard output. It is a filter, not an in-place editor. Use it in a pipeline or redirect its output deliberately, and choose a separate destination file when preserving the original matters.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

DEV Community: dpm_bush

Choosing a WinSCP Alternative: Start With the Job, Not the App

First, identify the task you need to replace

Shortlist by operating system and workflow

If you want a free, cross-platform file-transfer client

If you need SFTP plus cloud storage

If you’re on macOS

If you want a Windows SSH terminal and graphical SFTP

If automation is the priority

Migrate without breaking a working setup

A practical decision rule

Choosing a Termius Alternative: Match the Client to Your SSH Workflow

Start with the job you need the client to do

Match the alternative to your setup

You want a free desktop terminal

You need SSH, graphical SFTP, and tunnels on Windows

You mostly transfer files

You want a minimal, command-line setup

Treat migration as a security task

A practical decision checklist

Use the Linux tree Command to Understand a Project’s Structure

Get a focused overview

Install it if the command is missing

Shape the output around your task

Choose the right listing tool

Save a listing to share or review later

A few common surprises

Using echo in Linux: Quoting, Redirection, and When to Use printf

The shell processes text before echo sees it

Redirect output to a file

What do -n and -e do?

Use printf when the output needs to be predictable

A quick rule of thumb

Linux `export`: How Shell Variables Reach Other Commands

Shell variable vs. environment variable

Environment variables flow downward

Common uses: PATH and application settings

Check, remove, or stop exporting a variable

Make a setting available in future shells

When export is not recognized

Use Linux `watch` for Live Command Snapshots

Think snapshots, not streams

Practical checks

Make changes easier to spot

Quoting and shell behavior

When watch is the wrong tool

A quick troubleshooting checklist

Getting Started with tmux on macOS

Install tmux

Start a session and come back to it

The few keys worth learning first

Copying text to the Mac clipboard

Troubleshooting a couple of common snags

A practical way to think about it

pwd in Linux: Know Which Directory Your Shell Is In

What pwd tells you

Use it before working with relative paths

Logical and physical paths

pwd on Windows depends on the shell

A useful habit

Renaming Files in Linux: Safe mv Patterns and Batch Previews

Rename one file

Filenames with spaces or leading hyphens

Avoid an accidental replacement

Move and rename in one step

Preview a batch rename before changing anything

One last distinction

Unix vs. Linux: What the Names Actually Mean

First, separate the terms

Similar conventions don’t guarantee identical behavior

Licensing and development aren’t one-size-fits-all

Choosing a platform: start with the requirement

The takeaway

SSH Keys Explained: Public Keys, Private Keys, and Host Keys

The two halves of a login key

What happens during key authentication?

Host keys answer a different question

A passphrase protects the local key file

Quick checks when login fails

A Practical Guide to `tr`: Character-Level Text Processing in Linux

What do `-n` and `-e` do?

Common uses: `PATH` and application settings

When `export` is not recognized

When `watch` is the wrong tool

What `pwd` tells you

`pwd` on Windows depends on the shell