Execute as .test rather than ./test

. will auto-complete to ./ (type . and press Tab) at least in modern Bash shells, so you shouldn't have to use a complex or insecure (like PATH modification) solution.

If it doesn't auto-complete you might need to install the "bash-completion" package.

or.. perhaps giving the interpreter an alias in the bashrc file and then simply

   p  file

It is possible to write such a function:

p() {
 ./"$@"
}

in your ~/.bashrc. Then you'll be able to run p app arguments instead of ./app arguments. This solution works for executables of any type, including scripts and binaries.

"$@" expands to appropriately quoted list of arguments passed to the function (preserving all special characters from glob or variable expansion), and, as @Scott pointed out, bash is clever enough to prepend ./ to the first one of them, preserving the rest.

You could put . to your $PATH by adding e.g. PATH=$PATH:. to your /etc/profile, this way you can execute file just by writing file, unless it is in some other folder in your path (e.g. /usr/bin/). Note that this is generally not a good idea.

Why it's bad: Say you're in a situation where you don't fully trust the contents of a directory - you've downloaded it from somewhere dodgy and you want to investigate it before running it, or you're a sysadmin helping some user by looking in their home directory, etc. You want to list the directory, so you try to type ls, but oops, you make a typo, and ended up typing sl instead. The author of this malicious directory anticipated this and put a shell script in it called "sl" which runs 'rm -rf --no-preserve-root /' (or something more malicious like installing a rootkit).

(Thanks @Muzer for the explanation)

You can call the interpreter, for example

bash test

In this case, the script will run even if it has neither a shebang line (eg #!/bin/bash) nor an executable bit. You will have to know the correct interpreter to run it also. You could read the shebang line of the file first to make sure you call the correct interpreter, for example if the shebang line says

#!/usr/bin/env python3

you would call

python3 test

As far as I know, there is no way to achieve it unless you include file in env path, so you could run it just typing: file

.file won't work since that is a different file name. It is a file called .file and not ./file.

I sense that slash may be difficult to type for you because non-english layout, maybe? In that case, it also happens to me, so I frequently swap my keyboard layout to english by pressing Alt+Shift in Windows (I use Linux from ssh)

People have suggested adding . to PATH, which is dangerous because it creates a risk that you will accidentally run a malicious program planted in a world-writable directory.  But, if you have executable programs in a few directories that you own and are writable only by you, then it’s safe (fairly safe?) to put those director(ies) into PATH, by adding a line like

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

to your ~/.bashrc file.  Of course this means that you can run a program from one of those directories from anywhere in the filesystem.  For example, you could cd /etc and type foo, and it would run ~/dev/myprog1/foo.  This has the minor drawback that you can’t have programs by the same name in more than one of the directories.  Specifically, if you have programs called foo in both ~/dev/myprog1 and ~/dev/myprog2, you won’t be able to run the second one except by specifying a path.  Likewise if you have a ~/dev/myprog1/cat — but why would you want to?

Another approach, if you have just a few programs that you do this with, is to define aliases for them:

alias gizmo='./gizmo'
alias gonzo='./gonzo'

Or you can call the aliases .gizmo and .gonzo if you find that more intuitive.

Actually, this has, to an extent, the same security risk as putting . into your PATH.  If a malicious user can read your .bashrc and see your aliases, then he might put malware called gizmo and gonzo in random directories in the hopes that you will run it.  It’s better to make these use absolute pathnames:

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

By the way, you should avoid naming an executable test, because that is a shell builtin command, and you can run a program by that name only by specifying a path or some other trick.

If we're allowed to start configuring things

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

Most modern distros include ~/.local/bin in $PATH already (add export PATH="$HOME/.local/bin:$PATH" to your ~/.profile if yours doesn't). Then you can use x file to run ./file.

Don't try to define a . command. The command . script already runs script in the current shell. This allows script to define environment variables for the current shell.

To expand on Zanna's answer about interpreters (sorry, no rep for a comment): an "interpreter" for native executables (aka binary ELF files) is the dynamic loader (ld.so), but it typically does not understand the syntax you want:

$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>

(also, unless you symlink ld.so into your path, you'd still need to write /s)

If we're allowed to make helper scripts, you could make a helper that adds the pwd to the PATH, then run

. pathhelper    #adds pwd to path
file            #now it can be run without ./

This avoids adding "." to the path and polluting your .profile with every path you might at some point want to run something in.

We can take this approach a step further by making a helper that launches a new shell with a modified PATH. If it takes a directory as a parameter (using the pwd as a default), it would function like a pushd that edits the path. You might have to be mindful that any changes to other environment variables would be lost when exiting the subshell, but in a long-running shell your PATH variable won't get all cluttered up. Depending on your workflows this might be advantageous.

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

But I guess if you wanted to run with it you could hack pushd and popd so they can make the same modifications to the path without without making a subshell which will lose other changes.

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(You can't do the same with cd because it doesn't have an analog to popd.)

You could also make a dedicated pair of helpers to just push and pop PATH entries. What works best really depends on your usage patterns.

You can use . script.sh syntax as long as the script you wish to execute is in the current directory.

You can also prefix with the interpreter, like sh or bash. example: bash script.sh