How to access the desktop with cygwin - cygwin

I want access to my windows 10 desktop with Cygwin. I tried this
$cd cygdrive/c/
$ls -al
But I can't see no one folder named "Desktop".

As you discovered the Desktop for any user is located in the disk at
C:\Users\[username]\Desktop
and its equivalent for Cygwin is
$ cygpath -u 'C:\Users\[username]\Desktop'
/cygdrive/c/Users/[username]/Desktop
It is NOT a Cygwin specific issue. Also with Windows Commond Prompt there is no
Desktop folder at the root of the C: disk structure
Microsoft Windows [Version 10.0.17134.472]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Marco>cd \
C:\>dir
Datenträger in Laufwerk C: ist Windows
Volumeseriennummer: 98EE-C713
Verzeichnis von C:\
15.07.2018 12:13 <DIR> inetpub
19.06.2018 16:34 <DIR> Intel
12.04.2018 00:38 <DIR> PerfLogs
05.10.2018 12:15 <DIR> Program Files
30.12.2018 04:27 <DIR> Program Files (x86)
18.07.2018 16:39 <DIR> SWSetup
18.07.2018 16:51 <DIR> temp
19.09.2018 10:44 <DIR> Users
03.01.2019 23:07 <DIR> Windows
0 Datei(en), 0 Bytes
9 Verzeichnis(se), 174.164.725.760 Bytes frei
C:\>
Explorer is showing a Virtual structure putting together the User data folders and the Disks at the same level.

I think that OneDrive is automatically "eating" the Desktop folder. Look here:
/cygdrive/c/users/[user-name]/OneDrive/Desktop.
For me it worked.....

Related

tar command with -zxvf not extracting contents as expected

(ubuntu 18.04)
I'm attempting to extract an odbc driver from a tarball and following these instructions with command:
tar --directory=/opt -zxvf /SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gz
This results in the following output:
root#08ba33ec2cfb:/# tar --directory=/opt -zxvf SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gzSimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/GoogleBigQueryODBC.did
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/release-notes.txt
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/Simba Google BigQuery ODBC Connector Install and Configuration Guide.pdf
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/docs/OEM ODBC Driver Installation Instructions.pdf
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/simba.googlebigqueryodbc.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/odbc.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/setup/odbcinst.ini
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/SimbaODBCDriverforGoogleBigQuery32_2.4.6.1015.tar.gz
SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015.tar.gz
The guide linked to above says:
The Simba Google BigQuery ODBC Connector files are installed in the
/opt/simba/googlebigqueryodbc directory
Not for me, but I do see:
ls -l /opt/
total 8
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux
And:
ls -l /opt/SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux/
total 52324
-rwxr-xr-x 1 1000 1001 400 Apr 26 00:39 GoogleBigQueryODBC.did
-rw-rw-rw- 1 1000 1001 26688770 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery32_2.4.6.1015.tar.gz
-rw-rw-rw- 1 1000 1001 26876705 Apr 26 00:39 SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015.tar.gz
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 docs
drwxr-xr-x 1 1000 1001 4096 Apr 26 00:39 setup
I was specifically looking for the .so driver file. All the above is on a docker container. I tried extracting the tarball locally on Ubuntu 18.04 (Same as my Docker container) and when I use Ubuntu desktop gui to extract by double clicking the tar.gz file and then clicking 'extract', I do indeed see the expected files.
It seems my tar command (tar --directory=/opt -zxvf /SimbaODBCDriverforGoogleBigQuery_2.4.6.1015-Linux.tar.gz) is not extracting the tarball as expected.
How can I extract the contents of the tarball properly? The tarball in question is the linux one on this link.
[edit]
Adding screens of contents of the tarball per comments. I had to click down two levels of nesting to arrive at 'stuff':
The instructions you linked to do not match the contents of the file I found from here. The first .tar.gz contains two other .tar.gz files. I looked into the 64 bit one and it has:
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/SimbaBigQueryODBCMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/ODBCMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/SQLEngineMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/DSMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/ErrorMessages/en-US/DSCURLHTTPClientMessages.xml
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/third-party-licenses.txt
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/libgooglebigqueryodbc_sb64.so
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/cacerts.pem
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/lib/EULA.txt
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/Tools/
SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015/Tools/get_refresh_token.sh
Your .so is in the lib directory. Based on the instructions it looks like you need to extract this file (or the 32 bit if appropriate) and rename, in this case SimbaODBCDriverforGoogleBigQuery64_2.4.6.1015 to simba/googlebigqueryodbc. The tar command is doing what it is told but the instructions are way off.

when the directory name have "*" inside created by linux, it show unreadable character on windows 10

#!/bin/sh
DOMAINLIST='*.io.domain.fun io.domain.fun *.*.domain.fun'
for i in $DOMAINLIST
do
mkdir $i
done
This shell code run out unreadable directory name
on my windows 10 . chinese character set
$ dir
_2X68P~X.A _E2MJ8~X.FUN
on my linux
# ls -alh .
total 32K
drwxr-xr-x 5 admin administrators 4.0K 2022-04-09 12:33 ./
drwxr-xr-x 6 admin administrators 4.0K 2022-04-09 11:06 ../
drwxr-xr-x 2 admin administrators 4.0K 2022-04-09 12:33 *.io.17lai.fun/
drwxr-xr-x 2 admin administrators 4.0K 2022-04-09 12:33 *.a/
maybe this is a character set problem?
it's probably not a good practice, but you can escape special characters with \ (e.g. mkdir '\*.a')
I know now . Win10 can not have * in file or dir name!

WSL: Unable to view the folders (appear as file) in Windows explorer if using symlink, but works if symlink on the same directory

No idea why but it seems that Windows explorer unable to view symlinked directories that the target is not on the same directory as the source target.
Is there a way to fix it? As it also make win32 applications unable to read the files under the symlinked directory. (I understand Windows equivalent mklink exist, but I need to do it in WSL's ln.)
Thanks a lot.
Sysinfo:
Windows 10 Pro 2004 Build 19041.264
(No idea how to check WSL build number)
WSL2
Subsystem uname: Linux PC 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
Example:
$ pwd
/mnt/d/symlink_test/innerFolder
$ mkdir source
$ touch source/testfile
$ ls source
testfile
$ ln -s source target
$ ls -l
total 0
drwxrwxrwx 1 user user 4096 Jun 6 10:55 source
lrwxrwxrwx 1 user user 6 Jun 6 10:55 target -> source
Now view the output in Windows explorer:
As you can tell, the target folder is recognizable by Windows Explorer
As well as the file testfile is accessable in Windows Explorer
Counter Example:
$ rm -rf target #Just clean things up
$ ls
source
$ ln -s /mnt/d/symlink_test/innerFolder/source ../upper_target #make a symlink to upper dir, or any directory that is not in the same dir, with the source dir being absolute path
$ ls -l .. #List files on the upper dir
total 0
drwxrwxrwx 1 user user 4096 Jun 6 11:03 innerFolder
lrwxrwxrwx 1 user user 6 Jun 6 11:04 upper_target -> /mnt/d/symlink_test/innerFolder/source
$ ls ../upper_target
testfile
However, but now, if you view it in Windows Explorer, the upper_target will become a single file instead of a folder, like above:

From WSL, how can I determine if a file is hidden, according to Windows?

I'm running Python 3.5 on the Windows Subsystem for Linux on Windows 10, Ubuntu 16.04. When finding files, such as using os.walk, I want to filter out hidden files (and directories) such as "desktop.ini" and "Thumbs.db". But they look like regular files from Ubuntu.
Because I'm running Ubuntu, ctypes.windll doesn't load so those solutions aren't an option.
You will need to parse the output with something like sed or awk but the command cmd.exe /c dir /S /A:H will do what you are after.
Display all files with the hidden attribute /A:H in the current directory and recursively /S below it.
EDIT
the following is the output when i run the command from inside my windows user directory
➜ cd /mnt/c/Users/damo
➜ cmd.exe /c dir /A:H
Volume in drive C is OSDisk
Volume Serial Number is B8E3-7234
Directory of C:\Users\damo
25/11/2019 10:04 <DIR> AppData
20/02/2020 08:16 <DIR> IntelGraphicsProfiles
25/11/2019 15:42 <DIR> MicrosoftEdgeBackups
17/02/2020 10:04 7,864,320 NTUSER.DAT
25/11/2019 10:04 696,320 ntuser.dat.LOG1
20/02/2020 08:16 1,048,576 NTUSER.DAT{c17b7660-0d10-11ea-a41b-88b111e240a6}.TxR.0.regtrans-ms
25/11/2019 10:50 524,288 NTUSER.DAT{c17b7661-0d10-11ea-a41b-88b111e240a6}.TMContainer00000000000000000001.regtrans-ms
25/11/2019 10:50 524,288 NTUSER.DAT{c17b7661-0d10-11ea-a41b-88b111e240a6}.TMContainer00000000000000000002.regtrans-ms
25/11/2019 10:04 20 ntuser.ini
17/02/2020 10:08 21,126 ntuser.pol
12 File(s) 13,824,666 bytes
3 Dir(s) 325,835,501,568 bytes free
➜
Notice in this example i did not include the /S and i ran this from directly inside WSL.
Could you also check the version of CMD that you are using form WSL by issuing the following which cmd.exe which for me returns /mnt/c/Windows/System32/cmd.exe

NodeJS ZIP symlink and can't read them on Windows 10

I'm using Archiver in a NodeJS environment (running on linux) to create a ZIP with a structure like this:
/root
/documents
/doc1.pdf
/doc2.pdf
/doc3.pdf
/clientA
/doc1.pdf < symlink to ../documents/doc1.pdf
/clientB
/doc3.pdf < symlink to ../documents/doc3.pdf
Using these functions of ArchiverJS:
archiverInstance.append(filestream, {name: '/root/documents/doc1.pdf'})
archiverInstance.symlink('/root/clientA/doc1.pdf', '../documents/doc1.pdf')
When I download this ZIP on linux, I can open the symlinks.
# linux ubuntu 19.04
ls -l ~/root/clientA
lrwxrwxrwx 1 usr usr 28 oct 11 11:51 doc1.pdf -> ../documents/doc1.pdf`
But when I download this ZIP on Windows 10, symlinks are broken, using the standard "Extract" button from the windows explorer.
# windows 10
cd root/clientA
dir
10/11/2019 02:49 AM <DIR> .
10/11/2019 02:49 AM <DIR> ..
10/11/2019 02:49 28 doc1.pdf < click on it = PDF corrupted
1 File(s) 28 bytes
2 Dir(s)
Why this does not work on Windows 10? And is there an alternative to make it work?
Thanks

Resources