How do I cd down one level ?

[sofasurfer]

CD up one level with cd ..
DC down one level on the directory tree by typing the <cd name_of_directory>
But how do I cd from </home/user/level1/level2> down to </home/user/level1>? I just want to drop back ONE level from a sub, sub directory but not back to the directory tree.

 

[osprey]

CD up one level with cd ..
DC down one level on the directory tree by typing the <cd name_of_directory>
But how do I cd from </home/user/level1/level2> down to </home/user/level1>? I just want to drop back ONE level from a sub, sub directory but not back to the directory tree.

If I'm understanding you correctly, to go from "level2" to "level1" in your example, one can use the command:

cd ..

as follows:

[tom@min ~/level1/level2]$ pwd
/home/tom/level1/level2
[tom@min ~/level1/level2]$ cd ..
[tom@min ~/level1]$ pwd
/home/tom/level1

 

[sofasurfer]

Thanks. I should have known that.

 

[KGIII]

I wrote about this one quite a while ago. You can also go up multiple levels with cd ../../../ or some such.

 

[KGIII]

Also, let's say you were in ~/Downloads and you changed your directory to ~/Documents. You can return to your previous PWD with cd -.

And I found said article:

Let's Learn About Absolute And Relative Paths • Linux Tips

In your Linux journey, you'll use both absolute and relative paths. It's important to know the difference. Read on to learn more!

linux-tips.us

 

[dcbrown73]

..

 

[bob466]

Not something I do these days.

 

[sofasurfer]

Thanks for all your help. Problem solved.

 

[MikeRocor]

Also, let's say you were in ~/Downloads and you changed your directory to ~/Documents. You can return to your previous PWD with cd -.

A huge "thank you" for that - it's a new one to me. I'm usually using busybox ash instead of bash (so no pushd/popd) but cd - works and repeating it toggles between to directories, which is very useful indeed.

 

[KGIII]

A huge "thank you" for that - it's a new one to me. I'm usually using busybox ash instead of bash (so no pushd/popd) but cd - works and repeating it toggles between to directories, which is very useful indeed.

Not a problem. I'm glad you found it useful. While searching for the article in question, I stumbled across the article where I'd described that and decided to share it.

How To: Return To The Previous Working Directory In The Terminal • Linux Tips

Today is another easy day, but one that should be productive, where we'll learn how to return to the previous working directory.

linux-tips.us

 

[Diputs]

Thanks for all your help. Problem solved.

Not all problems must be big


In Windows CMD you can even run

cd..

( note the absence of any white space )
but that doesn't work in Unix/Linux

If I could change anything, that would be my idea to let Linux behave. This command is used a lot, so ...
Then again, you can create a script named cd..
I guess.

It also proves some way that Windows CMD has things Linux Shells can't (but should)

 

[JasKinasis]

Not all problems must be big


In Windows CMD you can even run

cd..

( note the absence of any white space )
but that doesn't work in Unix/Linux

If I could change anything, that would be my idea to let Linux behave. This command is used a lot, so ...
Then again, you can create a script named cd..
I guess.

It also proves some way that Windows CMD has things Linux Shells can't (but should)

I wouldn't say that.....Windows CMD is missing a LOT of basic features that the various Linux terminals/shells have by default.
For starters, CMD has a lot less useful tools installed. Compared to bash or zsh, CMD is little more than a barely functional toy, unless you take the time to trawl the web to download and install a bunch of GNU tools yourself. Which involves manually tracking down the windows binaries for them and running windows installers for each of them.
In Bash/zsh on Linux, you can simply install any missing tools there and then in the terminal, using your installed distributions package management tools.

The shortcomings of CMD and Powershell are exactly why Cygwin is the first thing I install on a fresh install of Windows (on my workstations at work). Cygwin installs a complete Unix/Linux like environment with bash and I have access to all of my regular terminal based Linux tools.

Since "upgrading" to Windows 11, I even prefer Cygwin over installing a full Linux distro via the WSL.
Cygwin doesn't involve having to boot an entire Linux distro inside Windows - it just emulates a Unix/Linux like terminal environment on top of Windows.

Anyway.....To explain the behaviour your're seeing - and the differences on Windows and Linux/Unix.

In the terminals in Linux/Unix (and in Windows), spaces are used as delimiters, in order to distinctly separate different tokens in the command line. BTW - it's also worth bearing in mind that cd.. would be a perfectly valid name for a file, or an executable in Linux and Windows.

The shells we use in Linux do NOT see cd.. (without a space) and cd .. (with a space) as the same thing.
When you enter the command cd .. (with a space), it looks for an executable file called cd and passes it the parameter ... Whereas if you enter cd.. (without a space)- the shell strictly looks for an executable file called cd... If it can't find that - it correctly throws an error message and does nothing else.

In Windows, it works exactly the same way. But in Windows CMD and Powershell, the cd command is a "builtin". It's a command that is built into the shell itself. Whereas in Linux/Unix - cd is a standalone, external executable, which can be used by other shells.

In windows, when you type cd .. (with spaces) - it runs the cd builtin and passes .. as a parameter - exactly as you'd expect.
But when you erroneously type cd.. (without a space) in CMD or powershell - it will first attempt to execute a file called called "cd.." (either locally, or in the systems $PATH) - if it can't find one, for some reason it won't complain, but it will instead execute the cd builtin and pass the rest of the line .. as a parameter.

You can prove this for yourself by opening cmd in Windows and creating a file called cd..:
e.g.

type nul > cd..

Now try entering the command cd.. (with no spaces).
Because the local file called cd.. is just an empty file - you will get an error message:

'cd..' is not recognised as an internal or external command, operable program or batch file.

So with the file there - CMD can see the file there, but it can't execute it - so it throws an error message.

Now if we remove the file called cd.. via the command del cd.. and then type cd.. (without the spaces) again.
This time, because there is no file called cd.. in the directory, it doesn't throw an error about "command not found", like we'd see in Linux/Unix. Instead, the builtin is ran and the conjoined .. is treated as a parameter and you'll be cd'd up a level to the C:\Users directory.

So I wouldn't say this is a feature of Windows CMD/Powershell per se. I'd say it's a quirk. A bug masquerading as a feature. And it's definitely NOT a feature that you should rely on in Windows, or ever expect to see in Linux/Unix shells. In shells like bash/zsh - the shell will do exactly what you tell it to. It doesn't try to second guess the users intentions. The user must be exact/verbose. If you make a typo - then the Problem Exists Between Keyboard And Chair (PEBKAC). It's a PICNIC (Problem In Chair, Not In Computer)!! Ha ha.

But if you do make that particular typo a lot - you could create an alias in your .bashrc (or another config file, if using a different shell).
e.g.

alias cd..='cd ..'

That will create an alias which will run cd .. whenever you accidentally type cd.. (without a space).

 

[Diputs]

cd..

I wouldn't say that.....Windows CMD is missing a LOT of basic features that the various Linux terminals/shells have by default.
For starters, CMD has a lot less useful tools installed. Compared to bash or zsh, CMD is little more than a barely functional toy, unless you take the time to trawl the web to download and install a bunch of GNU tools yourself. Which involves manually tracking down the windows binaries for them and running windows installers for each of them.
In Bash/zsh on Linux, you can simply install any missing tools there and then in the terminal, using your installed distributions package management tools.

The shortcomings of CMD and Powershell are exactly why Cygwin is the first thing I install on a fresh install of Windows (on my workstations at work). Cygwin installs a complete Unix/Linux like environment with bash and I have access to all of my regular terminal based Linux tools.

Since "upgrading" to Windows 11, I even prefer Cygwin over installing a full Linux distro via the WSL.
Cygwin doesn't involve having to boot an entire Linux distro inside Windows - it just emulates a Unix/Linux like terminal environment on top of Windows.

Anyway.....To explain the behaviour your're seeing - and the differences on Windows and Linux/Unix.

In the terminals in Linux/Unix (and in Windows), spaces are used as delimiters, in order to distinctly separate different tokens in the command line. BTW - it's also worth bearing in mind that cd.. would be a perfectly valid name for a file, or an executable in Linux and Windows.

The shells we use in Linux do NOT see cd.. (without a space) and cd .. (with a space) as the same thing.
When you enter the command cd .. (with a space), it looks for an executable file called cd and passes it the parameter ... Whereas if you enter cd.. (without a space)- the shell strictly looks for an executable file called cd... If it can't find that - it correctly throws an error message and does nothing else.

In Windows, it works exactly the same way. But in Windows CMD and Powershell, the cd command is a "builtin". It's a command that is built into the shell itself. Whereas in Linux/Unix - cd is a standalone, external executable, which can be used by other shells.

In windows, when you type cd .. (with spaces) - it runs the cd builtin and passes .. as a parameter - exactly as you'd expect.
But when you erroneously type cd.. (without a space) in CMD or powershell - it will first attempt to execute a file called called "cd.." (either locally, or in the systems $PATH) - if it can't find one, for some reason it won't complain, but it will instead execute the cd builtin and pass the rest of the line .. as a parameter.

You can prove this for yourself by opening cmd in Windows and creating a file called cd..:
e.g.

type nul > cd..

Now try entering the command cd.. (with no spaces).
Because the local file called cd.. is just an empty file - you will get an error message:

So with the file there - CMD can see the file there, but it can't execute it - so it throws an error message.

Now if we remove the file called cd.. via the command del cd.. and then type cd.. (without the spaces) again.
This time, because there is no file called cd.. in the directory, it doesn't throw an error about "command not found", like we'd see in Linux/Unix. Instead, the builtin is ran and the conjoined .. is treated as a parameter and you'll be cd'd up a level to the C:\Users directory.

So I wouldn't say this is a feature of Windows CMD/Powershell per se. I'd say it's a quirk. A bug masquerading as a feature. And it's definitely NOT a feature that you should rely on in Windows, or ever expect to see in Linux/Unix shells. In shells like bash/zsh - the shell will do exactly what you tell it to. It doesn't try to second guess the users intentions. The user must be exact/verbose. If you make a typo - then the Problem Exists Between Keyboard And Chair (PEBKAC). It's a PICNIC (Problem In Chair, Not In Computer)!! Ha ha.

But if you do make that particular typo a lot - you could create an alias in your .bashrc (or another config file, if using a different shell).
e.g.

alias cd..='cd ..'

That will create an alias which will run cd .. whenever you accidentally type cd.. (without a space).

Yes, so my point was that Windows has features, Linux hasn't, which I proved in my initial statement

Why it works ? Don't know. But I know it works for a loooong time.

Other stuff that also works is this : dir/s/b
( instead of : dir /s /b )

For the same reason this also works:
cd\windows
( in your C: drive )

Can you make it work in Linux ? Maybe. But I wouldn't try.
Still I'm happy it does in Windows.

I also don't like aliases for this reason:
It breaks the method of "everything is a file". If you see an alias in the history, seen on name it could be a file ... but it could also be an alias. I don't like that as it brings more confusion. Often, the weirdest things happen because admins make the weirdest constructions with aliases, but of course they don't tell you they're active.

 

[osprey]

<snip>

In Windows, it works exactly the same way. But in Windows CMD and Powershell, the cd command is a "builtin". It's a command that is built into the shell itself. Whereas in Linux/Unix - cd is a standalone, external executable, which can be used by other shells.

I was under the impression that cd was actually a builtin in bash:

[tom@min ~]$ help
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
These shell commands are defined internally.  Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list.

A star (*) next to a name means that the command is disabled.
<snip>
 cd [-L|[-P [-e]] [-@]] [dir]
<snip>

Instead of wading through the bash help and man texts, the following looks decisive on the matter:

[tom@min ~]$ type cd
cd is a shell builtin

 

[Vimmer]

yeah the most common approach is cd .. which takes you to the parent directory.

You can also do this to change to the last working directory you were in. It's useful if you jumped a bunch directories to get to the current one:

cd -

 

[rado84]

I found about .. a few months ago purely by accident. But I wonder what happens/does it even work with a single dot (cd .)?

 

[Vimmer]

I found about .. a few months ago purely by accident. But I wonder what happens/does it even work with a single dot (cd .)?

No, that command just means "change to the current directory". It works but why?

 

[Diputs]

yeah the most common approach is cd .. which takes you to the parent directory.

You can also do this to change to the last working directory you were in. It's useful if you jumped a bunch directories to get to the current one:

cd -

There's also people that do this:

cd ../../../..

 

[Diputs]

No, that command just means "change to the current directory". It works but why?

I guess just to keep consistency between commands, where the dot has more meaning as a function. Changing to the current directory isn't very useful, indeed. There's always a reason ... for example, imagine you're in a path of a removable disk, and you want to check if your disk isn't ... removed. A " cd . " command would fail, no ? The path you're in is only valid for the moment you changed to that path, not any moment after that, even though paths usually are ... stable, but that's pretty general.

 

[KGIII]

A " cd . " command would fail, no ?

I wouldn't say it 'fails' so much as it 'does what is intended'. It doesn't throw an error and leaves you in the current directory. As you know, the . is the current directory. It's just as unuseful as just using the cd command without any directory specified.