Wikipedia:Reference desk/Archives/Computing/2018 March 30

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 30

Can you hack in to idle wireless

If i have a pc or a mac in this case, and its wireless is on but not attached to anything, can someone break into it through the wireless? Assume no firewall is active, im thinking theoretically. — Preceding unsigned comment added by 2600:1003:b116:ca40:64d1:acc0:3ee7:8273 (talk) 30 March 2018

If your wifi is on it's not generally 'idle'. Even if it's not connected to anything, being 'on' most likely mean it's actively looking for access points. After all, that's how it can connect to access points in the first place. So with bugs, yes this process can be vulnerable to being compromised. E.g. Broadpwn [1] [2]. Even if it wasn't actively participating i.e. was just listening to stuff it received, this would generally mean there was some interpretation of what it was receiving so this could also be vulnerable although the more complex the process, the larger the attack surface is likely to be. Nil Einne (talk) 06:43, 1 April 2018 (UTC)

P.S. Also 'not attached to anything' is unclear. Mostly OSes have abandoned automatically connecting to unknown public wifi hotspots although it can still be an option. But even if it's not connecting to unknown hotspots, it's easily possible either someone could spoof one of the known ones (i.e. Evil twin (wireless networks)) or the real known one could compromise you. In other words, 'not attached' can be a fleeting thing if the OS is set-up to automatically connect to some known hotspot. (Spoofing a WPA2 protected hotspot is a lot harder since you need to know the PSK, and if you've obtained that there's a fair chance you'll either be compromising the AP or compromising the device while connected to the proper AP.) Nil Einne (talk) 17:11, 1 April 2018 (UTC)

Bizarre TV/monitor behaviour

We have a TV at the office that we use as a screen during meetings. It's a Vizio D65u-D2 4K TV and we all connect via an HDMI cable. It's been working fine for months, but over the last little while, people's laptop's have stopped being able to connect. Like, you unplug from a laptop where it's working fine, plug it into another laptop and the screen just stays blank. At first, everybody's laptops worked fine, then a few started experiencing this problem, and now several people have the same issue. We've reset the TV, tried different ports and different cables. We've all got Dell laptops of approximately the same vintage. I've tried Googling, but all I get is people with issues of Wifi connection (which works fine for us). Any pointers or suggestions? Matt Deres (talk) 21:52, 30 March 2018 (UTC)

Python Unicode Madness

I'm writing a small script that extracts two columns from a CSV file with UTF-8 text, formats them, and prints them back. I use Python 3.6.3 and the csv module. So far all is well. I get a reader, and iterating over it gives me a list of strings for each row. Now these strings can contain Unicode characters, but Python is content and thinks they are type class 'string'. But when I try to print them, I get "UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 35: ordinal not in range(128)". So I use str.encode("utf8") on them, and get objects of type class 'bytes'. Those I can print, but it is printed with the leading b and quote marks, and I can't e.g. use format() on them. So I try to use bytes.decode(), and I'm back where I started - and very unhappy. I finally gave up using nice string functions, and just opened the output file in binary and used file.write() to write the raw byte strings. But there must be a better way! I thought that the CSV part would be hard, but not that I would spend 5 hours digging through stack exchange, Python tutorials, and the documentation to find out how to print Unicode strings - in particular since in Python 3 all strings are Unicode strings. I suspect my problem has something to do with the fact that the csv.reader() returned the raw UTF8 bytes as a string. The decode() turns should turn it into a unicode string, but it turns it into a byte stream...please explain what is going on and how I can escape this labyrinth! --Stephan Schulz (talk) 22:11, 30 March 2018 (UTC)

@Stephan Schulz: I found [3] It says csv.reader() does not handle Unicode, but it gives an example wrapper "unicode_csv_reader" that allows for reading Unicode and also a UnicodeReader class. RudolfRed (talk) 22:25, 30 March 2018 (UTC)

Thanks. That, unfortunately, applies to Python 2.7.4 - the Python 3 version here does no longer contain this discussion, and I think it does not translate - the problem is the Python 3 distinguishes strings and byte sequenced, while Python 2 used string for both (I think). --Stephan Schulz (talk) 22:45, 30 March 2018 (UTC)

Assuming your opening the files with utf8, it should work:

#!/usr/bin/python3

# create sample data
with open("data.csv", 'w', encoding='utf-8') as outfile:
    outfile.write("1\t[ˈʏfsɪlɔn ɪː]\n")                # IPA
    outfile.write("2\t彼女たちの神託\n")                 # jp
    outfile.write("3\t그중 1명 이상은 사\n")             # ko
    outfile.write("4\tית, ולקיים בדיקת חמץ וביעור חמץ\n")  # he
    
# read it back in and display it
import csv
with open("data.csv", 'r', encoding="utf-8") as infile:
    for row in csv.reader(infile, delimiter='\t'):
        print ("#".join(row))

(language is grabbed out of the various ??.wikipedia homepages, apologies if it's inadvertently nsfw or something). -- Finlay McWalter··–·Talk 01:36, 31 March 2018 (UTC)

#!/usr/bin/python3

# create sample output
with open("data.csv", 'w', encoding='utf-8') as outfile:
    outfile.write("id\ttext\n") # header
    outfile.write("1\t[ˈʏfsɪlɔn ɪː]\n")                    # IPA
    outfile.write("2\t彼女たちの神託\n")                   # jp
    outfile.write("3\t그중 1명 이상은 사\n")               # ko
    outfile.write("4\tית, ולקיים בדיקת חמץ וביעור חמץ\n")  # he
    outfile.write("5\t⠰ ⠲ ⠳ ⠴ ⠵ ⠶ ⠷\n")                    # braille
    
# read it back in, mess around with it, and write it to a new CSV
import csv
with open("data.csv", 'r', encoding="utf-8") as infile, open("new.csv", 'w', encoding="utf-8") as newfile:
    reader = csv.DictReader(infile, delimiter='\t') 
    writer = csv.DictWriter(newfile, delimiter='\t', fieldnames=reader.fieldnames)
    writer.writeheader()
    
    for row in reader:
        if int(row['id'])%2==1: # only do the odd ids
            row['text'] = row['text'][::-1] # reverse
            
        writer.writerow(row)

-- Finlay McWalter··–·Talk 02:01, 31 March 2018 (UTC)

Thanks - I think that is what I'm doing...here is the heart of my code:

#!/usr/bin/env python3

import csv
from sys import stdout

def printPaper(authors, title):
    resfp1.write(authors)
    resfp1.write(b": \"")
    # [ more hand-wringing here ]

resfp1=open("bla.txt", "wb")
resfp2=open("bla.html", "wb")

with open('IJCAR-2018_review_summary_2018-03-30_nu.csv', "r", encoding='utf8') as csvfile:
    reader = csv.reader(csvfile)
    paperlist = [row for row in reader]
    for row in paperlist[1:]:
        printPaper(row[1].encode("utf8"),row[2].encode("utf8"))

resfp1.close()
resfp2.close()

...originally without the encode()s - if I then try to print the keys in printPaper(), I get the error. --Stephan Schulz (talk) 07:09, 31 March 2018 (UTC)

It sounds like you had a version where resfp1 wasn't opened in binary mode. Can we see whatever was closest to working in that case? --Tardis (talk) 21:21, 31 March 2018 (UTC)

What I've posted so far is the hack I hacked to hack around the issue. Below is a reconstruction of the original version:

#!/usr/bin/env python3

import csv
from sys import stdout

def printPaper(authors, title):
    print(authors, ": ", title)

with open('minimal.csv', "r", encoding='utf8') as csvfile:
    reader = csv.reader(csvfile)
    paperlist = [row for row in reader]
    for row in paperlist[1:]:
        printPaper(row[1],row[2])

...and here are input:

#,Authors,Title,Decision,"Average
total
score","Total
score","Overall
evaluation","Reviewer's
confidence"
3,"An Author",A Title,ACCEPT,0.7,"0,1,1","0,1,1","4,4,4"
4,Max Müller, Something about Logic,ACCEPT,1.3,"1,2,1","1,2,1","4,4,4"

...and depressing result:

An Author :  A Title
Traceback (most recent call last):
  File "./accepted_hack2.py", line 13, in <module>
    printPaper(row[1],row[2])
  File "./accepted_hack2.py", line 7, in printPaper
    print(authors, ": ", title)
UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 5: ordinal not in range(128)

Thanks! --Stephan Schulz (talk) 20:53, 1 April 2018 (UTC)

Your code works fine for me (Python 3.6.3 on Linux). I have to wonder - what do you see if (at the command line) you say file * - you should see (as I do)

 foo.py:      Python script, ASCII text executable
 minimal.csv: UTF-8 Unicode text

-- Finlay McWalter··–·Talk 21:33, 1 April 2018 (UTC)

I do:

accepted_hack2.py:         Python script text executable, ASCII text
minimal.csv:               UTF-8 Unicode text

Maybe I should have mentioned I'm on a Mac (though the error shows in both Mac Terminal and in xterm). I now suspect that Python thinks it need to print the output to an ASCII terminal, and hence to convert it to 7 bit ASCII (at least my terminals don't show Umlauts even if I cat files). It might be a problem with the environment, not Python. --Stephan Schulz (talk) 08:46, 2 April 2018 (UTC)

https://stackoverflow.com/questions/918294/python-unicode-in-mac-os-x-terminal -- Finlay McWalter··–·Talk 11:03, 2 April 2018 (UTC)

I don't have access to a Mac to verify, but on Linux if I run Python with env PYTHONIOENCODING=ascii python3 then sys.stdout.encoding is indeed ascii, and so

print("абвгд")

generates the 'ascii' codec can't... error you get. -- Finlay McWalter··–·Talk 11:12, 2 April 2018 (UTC)

Thanks - that is at least a workaround! setenv PYTHONIOENCODING utf-8 makes it work (the characters look funny on the Terminal, but I wanted to redirect things to a file, anyways. I really do think this is broken behaviour - Python should always send the same bytestream to the terminal, and it's the terminal's job to interpret it. Separation of concerns and all that! --Stephan Schulz (talk) 18:49, 2 April 2018 (UTC)