Other modifiers you can use in expansion are as follows:

Combinations of modifiers and qualifiers that you can use to get compound results are shown in the table below:

In the examples above, you can use other batch paramters besides %1 and PATH. Cmd.exe provides the batch parameter expansion variables %0 through %9.

Batch parameters can't be manipulated in the same manner that you can manipulate environment variables. You can't search and replace values or examine substrings within them. You can, however, assign the parameter to an environment variable and then manipulate the environment variable.

So, if I wanted just the file name dns.log from d:\logs\dns.log, I could use the following in a batch file:

@echo off
call :getfilename "d:\logs\dns.log"
exit /b

REM Determine just the file name

:getfilename
echo %~nx1

If I have the above batch commands in a file called test.bat, I would see the following when I ran it.

C:\Users\JDoe>test.bat
dns.log

If there is a Windows Registry key containing the file location and I want to query that key and extract just the file name, I could use commands such as the following if the file location was stored in LogFilePath for the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters:

@echo off

REM Regkey is set to the registry key containing the location of the DNS log 
REM file

set regkey="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters"

REM Regvalue is set to the value that is desired from the above registry key

set regvalue="LogFilePath"

REM log_file_location is set to contain the complete path to the log file nad
REM its name, e.g., d:\logs\dns\dns.log

FOR /F "tokens=3" %%G IN ('reg query %regkey% /v LogFilePath ^| find %regvalue%') DO set log_file_location=%%G

call :getfilename %log_file_location%
exit /b

REM Determine just the file name

:getfilename
echo %~nx1

References:

1. Using batch parameters
   Microsoft Corporation
2. Determing the location of a Microsoft Windows DNS log file from a command prompt
   Date: November 22, 2014
   MoonPoint Support

[/os/windows/commands] permanent link

$ tcpdump
tcpdump: no suitable device found

The problem can be addressed by changing the ownership or permissions of the Berkeley Packet Filter (BPF) file in /dev. The default permissions and ownership are shown below:

$ ls -l /dev/bpf*
crw-------  1 root  wheel   23,   0 Nov 30 22:42 /dev/bpf0
crw-------  1 root  wheel   23,   1 Dec  4 21:45 /dev/bpf1
crw-------  1 root  wheel   23,   2 Dec  4 15:39 /dev/bpf2
crw-------  1 root  wheel   23,   3 Nov 30 22:41 /dev/bpf3

To resolve the problem, I changed the ownership of the bpf0 file to the account I was using:

$ sudo chown jdoe /dev/bpf0
Password:

I also checked to see what the designation was for the wireless adapter in the system. It was en1.

$ networksetup -listallhardwareports

Hardware Port: Bluetooth DUN
Device: Bluetooth-Modem
Ethernet Address: N/A

Hardware Port: Ethernet
Device: en0
Ethernet Address: d4:9a:20:0d:e6:cc

Hardware Port: FireWire
Device: fw0
Ethernet Address: d4:9a:20:ff:fe:0d:e6:cc

Hardware Port: Wi-Fi
Device: en1
Ethernet Address: f8:1e:df:d9:2b:66

VLAN Configurations
===================

I then tried again to run tcpdump specifying the wireless interface; this time I received a "You don't have permission to capture on that device message with a reference to bfp1, so I changed the ownership on that file as well. I was then able to observe traffic with tcpdump.

$ sudo chown jdoe /dev/bpf0
$ tcpdump -i en1
tcpdump: en1: You don't have permission to capture on that device
((no devices found) /dev/bpf1: Permission denied)
$ sudo chown jdoe /dev/bpf1
$ tcpdump -i en1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes

I changed the ownership back to root on /dev/bpf0 to see if I could still run tcdump, but when I did so I was no longer able to observe network traffic with tcpdump.

$ sudo chown root /dev/bpf0
$ tcpdump -i en1
tcpdump: en1: You don't have permission to capture on that device
((no devices found) /dev/bpf0: Permission denied)

I could have just changed ownership of all of the bpfx files in /dev initially with sudo chown jdoe /dev/bbf*, but I wanted to determine if I only needed to change a specific one for the wireless interface, en1. Alternatively one can expand the permissions on those files, e.g., one can use sudo chmod 644 /dev/bpf*. When the system is rebooted the permissions/ownership will be reset, so you will have to take the same steps to run tcpdump subsequent to a reboot of the system.

I specifically wanted to check on DNS queries, so, after changing the ownership for the bpf file back to the account I was using, I specified port 53, but saw no data.

$ tcpdump -i en1 'port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

I wasn't able to observe the DNS traffic until I ended the VPN connection I was using when I ran the command. Once I disconnected from the VPN, I was able to check on the DNS queries from the system and the responses from a DNS server.

References:

1. Tcpdump Permission Denied on OS-X
   Date: June 12, 2007
   MoonPoint Support
2. Managing Wi-Fi from the terminal command line under OS X
   Date: February 28, 2014
   MoonPoint Support
3. No Interfaces Available In Wireshark Mac OS X
   Date: January 31, 2010
   langui.sh Languishing since 2008.

[/os/os-x] permanent link